2 Commits

Include renames

Author	SHA1	Message	Date
dtourolle	747ec0161c	fix(download): stop an empty download completing and then hanging the player ... Two halves of one failure, either of which is enough to produce an offline item that never starts. The worker marked a transfer `completed` without checking it produced any bytes, so a server that answered 200 with no body — an error page, a transcode that yielded nothing — renamed a zero-byte `.part` into place and published it as available offline. That is worse than failing: the retry budget never applies and the UI shows the item as ready. The media server then answered a request for that file with a span of `{ start: 0, end: 0 }`. `end` is inclusive, so `Span::len()` reported **one** byte: the response declared `Content-Length: 1` and streamed nothing, which Chromium's media loader waits on forever. The user sees a downloaded item that just never plays, with nothing explaining why. A zero-length file has no satisfiable range, so `span_for` now returns `None` and the server answers 416. An empty transfer is rejected as a network error, which keeps the `.part` for a resume and lets the existing retry budget do its job.	2026-09-07 22:24:45 +02:00
dtourolle	1b70926c36	feat(offline): play downloaded video, and drain the offline sync queue (0.4.6) ... Bundles this session's work plus the concurrent search/offline/player changes. Every gate passes on the combined tree: 885 frontend tests, 610 Rust tests, clippy clean, boundary clean, trace coverage 86%. Offline video playback — four separate defects, each of which alone stopped it: DR-133 A completed download's file_path is already absolute (the worker rewrites it on completion), but the player rooted it a second time and handed the webview /data/user/0/app//data/user/0/app/videos/x.mp4. DR-134 The asset protocol was never enabled: no protocol-asset feature and no assetProtocol config, so convertFileSrc produced URLs nothing answered. Also silently defeated the cached-thumbnail path, which fails soft to the server copy and hid it whenever the server was reachable. DR-137 Tauri's asset protocol answers a range-less request by reading the whole file into memory, and only advertises Accept-Ranges from inside its range branch, so the first request never learns ranges exist. Chromium gave up with PIPELINE_ERROR_READ after ~31s. Local media is now served by a loopback HTTP server: bounded 4 MiB chunks streamed from the file handle, every response length-delimited, and a range-less request answered with one chunk rather than the file. Confined by a per-session token and to the app data directory, because loopback is shared between apps on Android. DR-138 Release builds set usesCleartextTraffic=false, so Android rejected the request to that server before any I/O. A network-security-config exempts 127.0.0.1 only; a remote server must still be HTTPS. Downloads: DR-135 download_item never records media_type and the reconnect resolver read that NULL as 'audio', so a movie queued from a media card had its URL resolved by get_audio_stream_url and completed as an audio-only transcode. The item's own type now decides. DR-136 Rows already downloaded that way are requeued on reconnect, since prevention alone leaves them reading "downloaded" and still unplayable. Known limitation: a download taken at `original` quality is a byte copy of the source, so it can be any container. One such file is an AVI holding XVID, which the webview cannot play in any case — the media server serves it correctly and Chromium refuses it. That needs either a transcoded download preset or the native ExoPlayer surface work, and is not addressed here. Also fixes two ID collisions between concurrent work: DR-143 defined twice (search vs offline gate) and UT-131 defined twice (Episode Focus hero vs channel cap). The search requirement is now DR-147 and the channel-cap test UT-141, with their code references and matrix rows updated.	2026-08-09 16:38:07 +02:00