100 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
dtourolle	40d358ab52	docs: a verification plan for the native player ... Not a generic smoke test. Every case exists because something specific went wrong, and most were found on hardware after the suites were already green. The sequences are load-bearing. Two defects this cycle only appeared in a particular order of actions — play, enable background audio, background, foreground, exit — and testing the same features in any other order found neither. So the plan asks for that order explicitly rather than listing "background audio" as a feature to try. It also states plainly that a green conformance run is not sufficient evidence to ship, because both regressions introduced during this work passed conformance and were caught by a person using the app. Includes a symptom-to-cause table, because none of these presented as their cause: a dead play/pause button was an unobserved property, a black screen was a float that could not become a Duration, and a scrub bar with no scale was a duration of zero being believed. "Known open" lists what is deliberately unfixed so each gets a decision rather than a surprise — device-local resume, the unconfirmed handoff swap, and the broken side-by-side debug install whose own error message advises an uninstall that would destroy the real app's data.	2026-08-23 10:39:37 +02:00
dtourolle	7e23da46e2	fix(player): a junk duration from an engine must not panic the backend ... DR-252, and a regression I introduced in DR-245. `Duration::from_secs_f64` panics on a negative or non-finite value. The old PlayerBackend contract passed durations around as a bare Option<f64> and never promised otherwise, so junk flowed through harmlessly. LegacyPlayer converts that value to a Duration on the way into the MediaPlayer contract, which turned it into a hard panic. ExoPlayer reports C.TIME_UNSET — Long::MIN_VALUE, about -9.2e15 seconds — for any stream whose length it does not know. That is every background-audio handoff: /Audio/{id}/universal is a chunked, length-less transcode. So the panic fired exactly when the handoff started, killed the Rust backend mid-swap, and left a black screen with no controls. Caught on the device, in the user's own repro sequence: enable background audio, background the app, come back. Not by any suite — the conformance cases run against engines that report sane numbers, and nothing was asking what happens when one does not. One guard on the contract now, used by every engine crossing into it, rather than each adapter deciding for itself. mpv had the same unguarded conversion for its duration property and would have hit it the moment libmpv reported something odd. UT-222 pins the values: TIME_UNSET as seconds, negatives, zero, NaN and both infinities yield no duration; a real runtime survives. 791 Rust tests, mpv conformance still 9/9, clippy clean both ways.	2026-08-23 10:13:43 +02:00
dtourolle	e5b7003489	fix(player): a duration of zero is not a duration ... DR-251. Scrubbing was dead on Android because the seek bar had no scale: every position tick read `<position> / 0.0`. ExoPlayer reports C.TIME_UNSET until it has resolved a duration, and JellyTauPlayer.getDuration() maps that to 0.0. So the engine answered Some(0.0) rather than None, which satisfied every "unknown duration" fallback in the controller — `observed_duration()` was never consulted, and neither was the runtime the catalog had carried since long before anything started decoding. Zero is now read as "does not know yet" at each step, with a final fallback to the item's own duration. That fixes it for any engine that cannot answer, rather than for ExoPlayer specifically. Red first: the test asserts a controller whose engine reports nothing usable still reports the queued item's 1800s, and failed with None before the change. 790 Rust tests, clippy clean both ways.	2026-08-23 09:13:21 +02:00
dtourolle	5b5162dd1e	fix(player): closing the player stops every renderer, not the believed one ... DR-250. The user's diagnosis, and a better fix than modelling the handoff more carefully: a close that stops only what we believe is playing is fragile by construction. A close that stops everything is correct whatever the bookkeeping thinks. Two places it did not. The teardown's stop was gated on `didStartNativePlayback && !didStopBackendEarly` — flags describing what *this component* started. A background-audio handoff swaps the renderer underneath them, so after one they describe a player that is no longer making sound and the stop was skipped entirely. The audio stream kept running and the mini player adopted it, which is exactly why a movie reappeared as an audio track. It is unconditional now; `playerStop` is idempotent, so the cost of calling it when nothing plays is a no-op round trip, against the alternative of silently leaving audio running. And `PlayerController::stop` never cleared the handoff. Leaving the base offset and the active flag behind lets a later position read be interpreted against a handoff that no longer exists. Stopping now clears both. `didStartNativePlayback` had no remaining reader and is deleted rather than silenced — dead bookkeeping about which renderer was in charge is precisely the frontend playback state this contract is meant to remove, and the eslint ratchet caught it going one over. The underlying unconfirmed state swap is still there and still worth fixing — it is written up in media-player-controller.md. This makes the symptom impossible while that lands. 789 Rust tests, 1088 frontend, lint back at 158, clippy clean both ways.	2026-08-23 09:02:30 +02:00
dtourolle	888f0a2a5d	docs(specs): the background-audio handoff is an unconfirmed state swap ... Diagnosed on a device. The likeliest explanation for "audio keeps playing after I leave the player", which is the report this line of work started from. enter_background_audio and exit_background_audio are pure bookkeeping: a boolean and a base offset. Neither confirms the audio stream opened, nor that the webview <video> came back. exit_background_audio's own comment says the element "becomes the player again once it reloads" — a future event nothing waits for, while the flag calls the swap done the moment it is invoked. Foreground the app, then leave the player before the element has reloaded, and the stop is aimed at something that does not exist yet while the audio stream keeps running. The mini player then adopts a live audio session, which is why a movie reappears as an audio track and why it is intermittent. Same defect class as DR-238 … DR-241: state asserted rather than confirmed. It is what Phase::Opening and the open generation exist for — a handoff is an open in flight, and a close during one must cancel it. Today the handoff never reaches an engine as an open at all, which is why close_during_open_never_plays passes on all four engines while the bug survives. Credit where due: the sequence came from the user reproducing it deliberately, not from the logs.	2026-08-23 08:58:25 +02:00
dtourolle	7d60f7ed9c	fix(android): a Linux gate that outlived its caller broke the build ... `set_current_item` was `#[cfg(target_os = "linux")]` from when its caller was a `#[cfg]` branch too. d3ecd8ee correctly replaced that branch with a runtime question — "does this renderer draw the picture?" — which means the `else` arm is now compiled on every platform, including ones where it never runs. The gate stayed, so the Android build stopped compiling at that commit. It went unnoticed because nothing built for Android afterwards. CI's Android `cargo check` would have caught it; this branch has never been pushed. Also adds the widget's allocation origin to the video-surface log. A GtkBox is a no-window widget, so `widget.window()` is the parent's GdkWindow and the box sits at an offset inside it; if `draw_from_gl` does not honour the cairo translation GTK applied, the picture lands at the window origin instead of the widget's — misaligned by exactly that offset, which is the shape of a letterbox that does not line up. Logging the origin says whether that is what is happening before anyone changes the geometry.	2026-08-23 08:46:01 +02:00
dtourolle	d952a2ae55	fix(player): ExoPlayer can seek a transcode in place; mpv cannot ... A regression I introduced in DR-246 and did not catch, because the capability was declared once for "native engines" as though being native were the property that mattered. It is not. Speaking HLS is. ExoPlayer is a full HLS client: like hls.js it seeks within the VOD playlist it was handed and lets the server catch up. mpv's HLS demuxer will not make the server produce segments from a new offset, so it has to re-open the stream. Grouping them together declared false for both, so on Android a transcoded seek began re-opening the stream where it previously seeked in place — the same class of defect DR-238 was about, reintroduced on the platform I had not exercised. Capabilities::native() is gone, replaced by mpv() and exoplayer(), and the composition root chooses per platform through engine_capabilities(). Treating a category as a proxy for an ability is precisely the inference this design removes; a helper named after the category invited it straight back in. Not yet verified on a device. The conformance cases run against JellyTauPlayer in isolation and do not cover a transcoded seek, PiP, background audio or the media session — none of which have been exercised since the controller port.	2026-08-23 08:33:23 +02:00
dtourolle	954546434a	docs(specs): record what shipped, and where the design bent ... DR-242 … DR-247 are in. The spec now says so rather than reading as a proposal for work that already exists. One deviation is recorded rather than quietly absorbed: DR-246 called for the engines to own seek strategy outright, and they cannot — re-negotiating a stream needs the repository, which sits above them. The engine declares the ability and the caller acts on it. `determine_video_seek_strategy` therefore survives, correctly typed over a declared capability instead of over a guess, because the defect was its input rather than its existence.	2026-08-22 22:23:20 +02:00
dtourolle	9d6b4f819c	chore(player): a script for the conformance suite ... The desktop runner needed a hand-generated fixture and the Android one needed `-x :app:rustBuildUniversalDebug`, which nobody was going to remember. Both are now `bun run test:player` and `bun run test:player:android`. The fixture is generated on first use rather than committed: no media in the repo, and an exact duration, which the seek assertions depend on. The gradle exclusion carries its reason inline — raw gradle drives the Rust build through Tauri's android-studio-script, which expects a dev-server address file that only exists under `tauri android dev`, and the library already in jniLibs is what the test process loads.	2026-08-22 22:23:20 +02:00
dtourolle	6b3d853442	feat(player): seek strategy follows what the engine says it can do ... DR-246. The strategy used to turn on `is_hls` and `use_html5`, decided in a command handler on behalf of engines it does not own. That is how "who renders" came to mean "how do I seek", and why a transcoded seek silently did nothing the moment native video changed the renderer (DR-238). Engines now declare `Capabilities::seeks_transcoded_in_place` — true for hls.js, which seeks within the VOD playlist it was handed and lets the server catch up; false for mpv, whose HLS demuxer cannot make the server transcode from a new offset. The command asks whichever engine is rendering. Adding an engine no longer means editing a shared truth table. The item's transport is not read at the seek site any more; the compiler flagged it unused, which is the URL-shape input finally disappearing. A deviation from the spec, recorded deliberately: it called for the engine to own the decision outright. It cannot. Re-negotiating a stream needs the repository, which sits above the engine, so the engine states the ability and the caller acts on it. That still removes the defect — nobody guesses on another component's behalf — without pretending an engine can reach upward. Also fixes a latent race in the conformance suite, found by running it: the seek case asserted immediately, which passes on an engine that records the target when it accepts a seek and races on one that waits for the decoder to move. `Harness::await_seek` polls instead, the way the Android suite already did. It failed with machine load rather than with the code, which is the kind of test that teaches people to re-run until green. MpvPlayer 9/9 LegacyPlayer 8/9 - still only the mute/rate gap in the old trait 789 tests, clippy -D warnings clean with and without the feature.	2026-08-22 22:21:42 +02:00
dtourolle	5fcf58fa78	feat(player): the controller talks to one contract ... DR-245. PlayerController now holds a MediaPlayer instead of a PlayerBackend, and every engine reaches it through that contract. Deliberately a seam swap, not four rewrites: the existing backends are carried across by LegacyPlayer, so MPV keeps its EQ and normalisation, ExoPlayer keeps its media session, and nothing loses a feature to the migration. MpvPlayer stays available for conformance until it grows the audio-settings half. The substantive change is at the load site. Where the controller used to call load() and then play(), it now issues one open() carrying the item and where to begin — so the window a start position could be lost in is gone from the controller as well as from the engines. `state()` maps the engine's Phase back onto PlayerState using the queue, which is what knows the item. External behaviour is unchanged. Supporting pieces: - The contract gains set_audio_settings/audio_settings as *provided* methods. Engines that cannot honour them say so through Capabilities and inherit a no-op, rather than every implementation carrying an Ok(()) it does not mean. - PlayerBackend is implemented for Box<dyn PlayerBackend>, without which the boxed engine built at the composition root cannot be handed to anything generic over the trait. - StreamSelection::for_queued_item rebuilds a selection for an item already in the queue, without re-negotiating. The transport falls back rather than being sniffed out of the URL — that substring check is what DR-230 removed — and needs_transcoding is an exact stand-in because every transcode this app requests is HLS (DR-140). - default-run = "jellytau". The conformance binary made a bare `cargo run` ambiguous, which broke `tauri dev` outright. Caught by running the app rather than by any suite, which is the argument for doing both. 789 tests, clippy -D warnings clean with and without the feature.	2026-08-22 22:12:51 +02:00
dtourolle	20e683d705	feat(android): conformance on a device, and a start position for ExoPlayer ... DR-247. The desktop suite cannot reach ExoPlayer: it needs an Android Context and a Looper, so it exists only inside an app process. These are the same behaviours, asserted against the engine itself. Writing them forced the same gap open that mpv had. JellyTauPlayer.load(url, mediaId) had no way to express a start position, so every caller loaded and then seeked — the test could not even be written against the old signature, which is a stronger statement than a failing assertion. The position now goes to ExoPlayer with the media item via setMediaItem(item, startPositionMs), and the two-argument form delegates to it, so nothing else had to change. Running one suite against both engines settled something guesswork could not: seekWhileOpeningIsHonoured passes on ExoPlayer with no fix ExoPlayer already queues a seek issued before prepare() completes. So the lost-seek half of DR-241 was mpv-specific, and only the missing vocabulary for a start position was shared. That is the difference between "both engines have this bug" and knowing which one does. All seven cases pass on device (ROD2-W09, arm64). The fixture is a silent WAV synthesised in the cache directory at setup rather than committed or pushed: no binary in the repo, no adb step, and an exact duration, which the seek assertions depend on. Also adds the instrumentation runner to defaultConfig and teaches sync-android-sources.sh to mirror src/androidTest, the way it already mirrors src/test — so the canonical tree stays the only place tests are edited. Run: ./gradlew :app:connectedUniversalDebugAndroidTest -x :app:rustBuildUniversalDebug	2026-08-22 21:32:59 +02:00
dtourolle	8904acb5f7	feat(player): run the old backend through the new contract ... DR-245, first half. `LegacyPlayer` implements `MediaPlayer` over the existing `PlayerBackend`, so engines not yet ported — ExoPlayer, the webview element, the null backend — keep working while `PlayerController` moves across. Without it the port would have to land all four engines at once. It also makes the two designs comparable on one engine and one file. `open` reproduces the old sequence faithfully: load, play, then seek for a start position, with the seek's failure ignored exactly as callers used to ignore it. Making it pass would defeat the point. Running both engines over the same media is more informative than expected: MpvPlayer 9/9 LegacyPlayer 8/9 - transport_settings_round_trip fails Two things fall out of that. The start-position case now passes on *both*, because DR-241 was fixed inside MpvBackend rather than only in the new engine — so the suite confirms that fix independently, on a path it was not written against. And the one genuine failure is a capability gap rather than a bug: the old trait has no mute and no playback rate, so `LegacyPlayer` reports them unsupported instead of folding mute into volume and losing the user's level. That is the abstraction earning its keep on the first run: a missing capability that was previously invisible is now a named, failing case. The runner takes an engine argument: player-conformance <media-file> [mpv|legacy]	2026-08-22 21:23:39 +02:00
dtourolle	a3190cd52b	feat(player): MpvPlayer, and a runner that verifies it without the app ... DR-244. The first real engine on the contract, and the tooling to interrogate it in isolation. The point of difference from MpvBackend is `open`: the start position is applied at load time via mpv's own `start` option, instead of being seeked to afterwards. loadfile is asynchronous, so a seek issued after it targets a player with nothing loaded, fails, and was discarded. A seek that does arrive during Opening is held and applied on FileLoaded, so no caller has to know where that window begins or ends. `close` clears state before issuing the stop, so an open still in flight checks it on FileLoaded and cannot proceed to play after the caller has stopped it. It is idempotent: callers legitimately close twice on teardown. Every property the event loop matches is observed, per DR-239. The runner is a separate binary that links libmpv and nothing else, so a wrapper can be verified without building or launching the app — which is what made the previous round of playback debugging so slow. Audio and video go to null, so it is safe on a headless runner and does not claim the speakers. It lives behind a `conformance` feature and exposes one entry point rather than making the player module tree public. cargo run --features conformance --bin player-conformance -- <media-file> All nine cases pass against real libmpv. Verified the suite can fail: reverting `open` to the old load-then-seek behaviour makes opens_at_a_start_position fail and restoring it makes it pass, so DR-241 is now a test rather than an anecdote.	2026-08-22 21:18:10 +02:00
dtourolle	f4892f4cb2	feat(player): FakePlayer and the conformance suite ... DR-243. One set of behaviours every engine must satisfy, written before the second engine exists so it cannot encode whatever the first happens to do — which is how three playback implementations drifted apart in the first place. FakePlayer models the one behaviour that matters most: opening is not instantaneous. `open` parks in Phase::Opening until complete_open() is called, so a test can put a seek into that window deliberately. That window is where DR-241 lived, and it was previously unreachable from any test. The suite drives readiness through a Harness rather than sleeping — the fake completes on demand, a real engine waits for its own readiness event. A timing-dependent suite is worse than none, because it teaches people to re-run until green. Nine cases, each naming the defect it prevents: opens_at_a_start_position DR-241 - starts there, never at zero seek_while_opening_is_honoured DR-241 - held, not discarded seek_while_opening_overrides_start later intent wins pause_and_play_are_observable DR-239 - state an engine cannot hide close_is_silent_and_idempotent stopped must mean silent close_during_open_never_plays an open cancelled by close must not come back to life `audible()` may return None for engines that cannot answer, which skips the silence assertions rather than passing them vacuously — an assertion that cannot fail is worse than an absent one. Also adds MediaItem::sample: the struct has twenty-odd fields, almost none of which a given test cares about, and repeating the literal per test is how a new field ends up added in thirty places.	2026-08-22 21:18:10 +02:00
dtourolle	3b91922cca	feat(player): the MediaPlayer contract ... DR-242. Intent, not device operations. `open` carries the start position, so no caller sequences load-then-seek and none can race an engine's asynchronous load — the engine is the only layer that knows when its pipeline can accept a position, and it absorbs that internally by deferring or re-opening. `seek` states a destination and nothing else. Whether that is an in-place seek or a re-opened stream is the engine's business: hls.js seeks within a VOD playlist, mpv's HLS demuxer cannot make a server transcode from a new offset. Callers stop guessing on behalf of engines they do not own. `snapshot` is one coherent read rather than a dozen getters, because reading position and duration separately is how a player reported <position> / 0.0 when a file unloaded between the two calls. `Phase::Opening` names the state the previous design could not express, and is the direct cause of DR-241: a seek arriving with nothing loaded had no phase to be queued against, so it was discarded. `Capabilities` exists so callers adapt without naming engines. If a caller ever branches on which engine it holds, this struct is missing something — engine identity leaking into callers is the coupling DR-238 came from. Nothing consumes it yet; PlayerController is ported in DR-245. Carries an explicit allow(dead_code) tied to that step rather than being hidden behind cfg(test), because it is production code being built in shippable pieces.	2026-08-22 21:17:50 +02:00
dtourolle	f388777185	docs(specs): one player contract, three interchangeable engines ... A day of debugging Linux native video produced four defects (DR-238 … DR-241) and one regression from fixing them in the wrong place. None of them were mpv bugs. All four trace to the same missing seam. `PlayerBackend` abstracts a *device* — load, then seek — rather than an *intent*. A start position is therefore not expressible, so every caller sequences load-then-seek itself and each races the engine's asynchronous load independently. That is why resume worked through the adapter, which seeks after "file loaded", and silently failed through the command, which seeks immediately: two callers, one intent, two behaviours. The same gap put transport rules above the engines. Whether a stream can be seeked in place was decided by a truth table in a command handler, on behalf of engines it does not own, which is how `use_html5` came to mean both "who renders" and "how do I seek". And nothing in the contract obliged an engine to report its own state, so a handler for mpv's `pause` property sat unreachable while the UI waited for an event that never came. Supporting evidence for the diagnosis: commands/player/mod.rs is 3,561 lines and is where "stop → rebuild URL → update queue → load → seek" lives; player_play_item needed a cfg(not(linux)) guard; and the frontend carries didStartNativePlayback, didStopBackendEarly and hasPerformedInitialSeek — playback state in the UI, which contradicts the one-directional rule. The proposal is a MediaPlayer contract whose `open` carries the start position, whose `seek` states a destination and leaves in-place-versus-re-open to the engine, whose `snapshot` is one coherent read, and whose `Phase` includes `Opening` — the state the previous design could not express and the window a seek was lost in. Testability is the half that makes it worth doing: one conformance suite run against every engine, and a FakePlayer that lets the controller, queue, autoplay and session logic be tested with no engine at all. The suite is written before the second engine on purpose, so it cannot encode whatever the first happened to do. Migration is a strangler in eight steps; the first three are pure addition.	2026-08-22 21:17:50 +02:00
dtourolle	14b6a8609d	fix(player): three defects native video exposed, and the logs to see them ... Each of these was invisible while Linux video played in the webview, and each became reachable the moment mpv started rendering. DR-238 — a transcoded seek re-negotiates the stream on every renderer, not just the webview. `determine_video_seek_strategy` treated `is_hls` as a proxy for "seekable in place", which held only because hls.js was always the HLS renderer: it seeks within the VOD playlist it is handed and lets the server catch up. mpv's HLS demuxer cannot make Jellyfin transcode from a new offset, so with native video on, every transcoded seek became a backend seek that silently did nothing. One cell of the truth table changes; all four webview cells are byte-identical. DR-239 — properties the mpv event loop handles are now observed. libmpv delivers PropertyChange only for properties registered with observe_property, so the `pause` arm was unreachable code that read as implemented: StateChanged was never emitted and the play/pause control never moved. UT-218 asserts the two lists agree, so the class cannot recur. DR-240 — fullscreen moves whatever owns the pixels. requestFullscreen() fullscreens the *document*, which sufficed while the <video> element lived inside it and WebKit scaled it. A native surface is drawn behind the webview at window size, so a document-only fullscreen expanded the page and left the picture at its old size — on WebKitGTK, a maximised window with decorations still holding a strip of the screen. Measured on a 3440x1440 panel: 1361 tall before, 1440 after. DR-241 — a seek issued before mpv has a file to seek in is honoured rather than dropped. loadfile returns as soon as the command is queued, so `time-pos` does not resolve yet and setting it fails. The two callers that always hit that window are resume and a transcoded seek, both of which re-open the stream and then ask for a position; the failed seek was discarded and playback began at zero. Also adds the instrumentation that made the diagnosis possible rather than speculative: an entry log on player_stop, a render-size log that re-fires on change instead of latching once, and decoded-vs-display video geometry on file load. The last of those retired a wrong theory — a picture that does not fill an ultrawide turned out to be a 16:9 source with its letterbox baked in, not a rendering fault.	2026-08-22 21:17:29 +02:00
dtourolle	d3ecd8ee91	feat(video): mpv plays video on Linux, composited under the webview ... DR-231 works. Video and audio, drawn by mpv into a framebuffer we own and blitted into the default vbox's draw handler with `gdk_cairo_draw_from_gl()`. The widget tree Tauri built is untouched, so nothing here can be invalidated by a Tauri upgrade that assumes its own layout. That settles finding 2 of playback-backend-unification.md on Linux by demonstration rather than argument, and completes the half of G1 the spike could not test. Three pieces had to land together, none of which existed before: - mpv was configured with `video: no` and no video output, so it had never decoded a frame in this app. Now `vo=libmpv` when native video is on. - `player_play_item` skipped loading into the native backend on Linux behind a `#[cfg(not(target_os = "linux"))]`, because the webview always played video there. With the webview no longer loading it, that guard meant *nothing* played — no picture and no audio, which reads as a broken stream rather than as a file nobody was given. - The webview paints its own opaque background. Android clears it through a Kotlin bridge from `enableNativeVideoCompositing()`; the CSS half of that already ran on Linux, so only `transparent: true` on the window was missing. Until it was, the frame was rendered correctly and covered by white. Frame pacing is polled, not pushed. The tick callback asks mpv `has_frame()` and draws only when the answer is yes. Both neighbouring designs were tried and both fail, in ways that point at the wrong culprit: - Waiting on mpv's update callback before rendering *deadlocks*: mpv does not progress until the client renders, so if the client waits to be told, the two hold each other. The file loads, one frame appears, and everything stops. - Rendering every frame-clock tick and reporting a swap each time claims a presentation far more often than one happened. It plays, and judders badly — which reads as a GPU or compositing limit, exactly as the spike warned. The update callback survives as a hint and does the least it safely can from an mpv thread: set an `AtomicBool`. It must not touch GTK — `idle_add_local*` requires the caller to own the main context and panics from there — and it must not hold the `Rc<RefCell<..>>` state, which is not `Send`. Two memory-safety fixes in this file's own short history, both worth recording because neither announced itself: - The callback context was handed over with `Rc::into_raw` (a pointer to the Rc's *contents*) and read back as `*const Rc<..>`, reinterpreting a RefCell as an Rc and corrupting its refcount on the first clone. mpv invokes the callback immediately, so this happened before anything drew. The symptom was the process ending quietly with status 0. - The surface was attached before the player backend was constructed, so the mpv handle it needs had not been registered yet and it found null every time. Teardown (DR-232) is confirmed working on a real run: callback unregistered, render context freed, GL objects released with the context still current, boxed callback state reclaimed only after mpv can no longer reach it — no crash. Still behind JELLYTAU_NATIVE_VIDEO=1 and off by default. Known open: whether exiting the player stops mpv (reported, evidence ambiguous, needs re-checking now the picture works), hardware decode (DR-236), and deleting the webview video path (DR-235).	2026-08-22 14:22:58 +02:00
dtourolle	2f637d4775	feat(video): let mpv decode video at all, behind one shared flag ... mpv has never decoded a video frame in this app: the backend sets `video: no` unconditionally, because Linux video has always been the webview's job and decoding it twice would burn a core for a picture nobody sees. The render path built in the previous commit therefore had nothing to draw. With native video on, mpv is configured for video *and* `vo=libmpv` — the render API only works through that output, and the default would try to open a window of its own. Set at construction, because mpv resolves its video output when it initialises and flipping the property later does not re-open one. The flag lives in `player::native_video`, read by all three things that must agree: the backend (configured before anything plays), the surface (nothing to draw otherwise), and `get_player_status` (which tells the frontend whether to use a `<video>` element — two decoders on one stream would fight over the audio). A function rather than three `env::var` checks, because a capability answered in several places is a capability whose answers drift: four separate bugs this cycle came from exactly that shape. Also fixes an ordering bug the first run exposed. The surface was attached in `setup` before the player backend was constructed, and the mpv handle is registered *during* that construction — so it found nothing every time and logged "no mpv handle". Attaching after the backend exists is the whole fix. Confirmed on a real run: mpv accepts `vo=libmpv`, the GL context comes up on Tauri's vbox, and `mpv_render_context_create` succeeds — which also proves the libepoxy data-symbol handling is right, since a wrong `get_proc_address` would have taken SIGSEGV on the first GL call rather than returning cleanly. No frame has reached the screen yet. The webview is still opaque, so it will paint over anything drawn beneath it until transparency is set up. Security: quick-xml 0.38.4 carried RUSTSEC-2026-0194 (quadratic parse on duplicate attribute names) and RUSTSEC-2026-0195 (unbounded namespace allocation, memory-exhaustion DoS). `cargo deny` gates CI on advisories, so this would have failed the next release. Fixed by plist 1.8 -> 1.10, which pulls quick-xml 0.41. Licences, bans and sources still pass. UT-216 pins the flag's parsing: absent, empty, `0`, `no` and anything unrecognised all mean off. A half-set variable that half-enabled the renderer would configure mpv for video with nothing drawing it — audio over a black rectangle. Also removes a wall-clock timer from the waitForRepository late-arrival test, which failed once under load. The assertion is about ordering, so it now publishes on a microtask and cannot race.	2026-08-22 13:45:04 +02:00
dtourolle	45144cb6b0	feat(video): render mpv behind the webview, and collapse duplicated helpers ... DR-231 with the design the failed reparent forced. mpv's render API draws into an FBO we own; the texture is composited by `gdk_cairo_draw_from_gl()` in the default vbox's own `draw` handler. GTK draws a container before its children, so the webview lands on top for free — no reparenting, no GtkOverlay, and nothing a Tauri upgrade can invalidate by assuming its own widget layout. Split so Windows inherits the useful half: `mpv_render` is the portable side (render context, framebuffer, GL resolution) and `video_surface` is the GTK side that consumes it. Nothing in the former is GTK-aware. Three things the spike paid for, carried over rather than rediscovered: - libepoxy exports GL entry points as *data* symbols. `dlsym("epoxy_glFoo")` returns the address *of a function pointer*, not of code — returning it makes mpv jump into non-executable data and take SIGSEGV on the first GL call. The value is read out of that location instead. - Frame pacing goes through mpv's update callback plus `report_swap`. Its absence looks like a GPU or compositing limit (fine in a window, judders at fullscreen) and is neither. - The render context is created on `realize` and destroyed on `unrealize`, with the update callback unregistered *before* the free, so a callback cannot land on a freed pointer. That is DR-232 built in from the start rather than retrofitted: the spike had no teardown at all, which remains the likeliest explanation for the one SIGSEGV it could not reproduce. Writing it also caught a bug that would have looked like severe stutter: the update callback flagged a new frame but never asked GTK to repaint, so decoded frames would only have reached the screen when something else happened to invalidate the widget. Still off by default behind JELLYTAU_NATIVE_VIDEO=1. It compiles and is wired; no frame has been put on screen yet. Redundant code, continued. `formatSecondsDuration` had no caller. Three components had hand-rolled `formatDuration`: Queue's was byte-equivalent to the shared "mm:ss", while EpisodeFocusView and the library page shared an identical "1h 23m" shape the util did not offer — so that format joins the other two and all three components now call one function. A survey for exported symbols referenced only by tests returns 23 more. They are deliberately left: spot-checking found `setLogForwarder` is the injection seam for a lazily-initialised forwarder, and `getCachedImageUrl` is the read path of a thumbnail cache whose management UI exists in Settings. Neither is dead — one is test infrastructure and the other is an unwired feature, and deleting either would remove capability while looking like tidying. The list is worth working through deliberately, not in a playback branch.	2026-08-22 13:45:04 +02:00
dtourolle	7545de6cc7	refactor: delete two orphans, and record why the reparent design changed ... `resolveVideoSource` chose between a local file and a remote URL for video playback. Backend-owned stream selection took that decision into Rust — `media_local_selection` for a downloaded file, `get_stream_selection` for a streamed one — and its last caller went with it. What remained was the function plus sixty lines of tests exercising nothing that ships. `fittedVideoSize` computed the rendered size of a video letterboxed into its container. Nothing has ever called it: it arrived with the fix that made the video fill its viewport and was superseded by `object-fit: contain` in the same change. There is some irony in a helper that models letterboxing sitting unused beside a container that was not letterboxing at all — the bug fixed in the previous commit was CSS, and this function would not have helped. A survey for exported symbols referenced only by their own tests finds 22 more. Most are legitimate — test mocks, deliberate reset hooks, public utility APIs — and the rest are unrelated to this work, so they are left for a cleanup that can be reviewed on its own terms rather than smuggled into a playback branch. Also records in the spec why DR-231's design changed. Reparenting Tauri's webview into a GtkOverlay aborts the process on the first click: Linux calls `attach_resize_handler` unconditionally (the Windows path guards it with `is_decorated()`), and its handler walks webview -> GtkBox -> GtkWindow with an unwrap that an overlay breaks. So the webview is not moved at all — mpv draws into the default vbox's own `draw` handler via `gdk_cairo_draw_from_gl()`, and GTK's container-before-children order puts the webview on top for free. No reparent, one less widget, and nothing a Tauri upgrade can invalidate by assuming its own layout.	2026-08-22 13:45:04 +02:00
dtourolle	0445a6d0aa	docs(requirements): DR-234 is in progress, not proposed ... The renderer-derived codec source was built while chasing four Android bugs that all turned out to be the same defect, so it landed ahead of the spec that allocates it. Five call sites now read one source instead of re-deriving or hardcoding the webview's answer. Not Done: on Linux it still resolves per platform, because there is still only one renderer there. It becomes the runtime question the spec describes when mpv draws the picture.	2026-08-22 13:45:04 +02:00
dtourolle	a8c44145ff	fix(player): letterbox the picture, and stop racing the session ... Two bugs found by resizing the window during playback. Neither was introduced by this branch; both are the kind that only surface when somebody actually drags a window edge. The picture cropped and sat at the top instead of letterboxing. The video's flex wrapper had no `min-h-0`, and a flex item defaults to `min-height: auto` — it refuses to shrink below its content's intrinsic size, and a <video> reports the *media's* natural dimensions. So whenever the picture was larger than the window the wrapper grew past the viewport, the overflow went off the bottom, and what was visible was the top-left of an uncentred, uncropped image. `object-contain` was doing its job the whole time, inside a box that was the wrong size. This is also what put the picture at the bottom in fullscreen, reported earlier and unexplained until now. "Not connected to a server", shown as a *playback* error. The player page asks for the repository on mount, but the session is restored asynchronously at startup, so losing that race turned a perfectly good stream into a fatal error screen. `getRepository()` throwing instantly is right for a click handler, where the user is present; it is wrong for anything that runs on mount. `waitForRepository()` resolves as soon as the session lands and still rejects when there genuinely is not one, so a real logged-out state surfaces — just not as a race. Worth recording how this was found, because it was nearly misdiagnosed: the symptom correlated with window resizes, but the log showed 230 Vite HMR updates against a single app start — the frontend was being remounted under the test by edits made while it ran, and a remount empties the in-memory auth store. The race is real and worth fixing on its own merits, but "resize causes it" was an artifact of how it was being observed, not a property of the bug. UT-215 covers the waiting contract: resolves when already restored, resolves when the session arrives late, still rejects when there is none, unsubscribes once settled, and leaves no armed timer to reject an already-resolved promise.	2026-08-22 13:45:04 +02:00
dtourolle	fecd6022fe	chore(traceability): shift this branch's ids clear of master's ... Master allocated DR-224 and UT-211 while this branch was in flight — the third collision on this work. Everything here moves up by one: DR-224..236 become DR-225..237, UT-211..213 become UT-212..214. UR-079, UR-080 and IR-033 were still free and are unchanged. Mechanical, and matched on each row's own text rather than on its number, so a row cannot be shifted twice or the wrong one caught. Master's DR-224 (the background-audio toggle) and UT-211 are untouched.	2026-08-22 13:45:04 +02:00
dtourolle	156b9e3684	fix(playback): ask the renderer what it can decode, in one place ... Four bugs, one cause. "What can this device decode" was answered in five places, four of which assumed the webview was decoding: - the device profile's direct-play codecs (cfg per platform, inline) - the transcoding targets (hardcoded "h264,hevc") - the direct-play audio narrowing (webview list, all platforms) - the client-side audio override (webview list, all platforms) - get_video_stream_url's VideoCodec (hardcoded "h264") On Android the decoder is ExoPlayer, so four of those were simply wrong there, and the costs were invisible without a device: - dts is in the tablet's own codec list, gets stripped from the profile, and is then forced to transcode by a rule about a renderer that is not playing it. - An hevc source whose *audio* is eac3 had its **picture fully re-encoded**. The server's own transcoding URL got this right — VideoCodec=h264,hevc, TranscodeReasons=AudioCodecNotSupported, video copied — but the moment a quality change or track switch re-opened the stream through our builder, the hardcoded h264 turned a cheap audio remux into a full transcode. That is a quality change silently making playback more expensive, on the exact path a viewer uses when playback is already struggling. `renderer_codecs()` and `renderer_can_decode_audio()` are now the single source, and all five sites read them. On the webview path every value resolves exactly as before, so desktop behaviour is unchanged by construction; on Android the profile becomes the device's own. The list is also what lets the server *copy* rather than re-encode: naming every codec the renderer can decode is what turns a transcode into a passthrough when the source is already playable. That is the whole of "use the best format available". Also corrects this branch's headline number where it is asserted — the architecture doc, the desktop-native-video spec and the spike. The measured 85% Android direct-play rate used a profile containing ac3/eac3; the device it was later verified on reports neither, so eac3 content correctly transcodes there. It is a ceiling for an ExoPlayer-appropriate profile, not what the app achieves, and realising any of it depends on this change. Left in place with the caveat rather than deleted, because the measurement is real — it just measures something narrower than it was quoted as measuring. Unverified: this changes what Android negotiates and has not been exercised on the tablet yet. Desktop is unchanged by construction but also unre-tested.	2026-08-22 13:45:03 +02:00
dtourolle	4f6cf22419	fix(player): tell the native backend's caller what it actually did ... Two defects found by running on an Android tablet, both invisible on the desktop, and both the same mistake: a rule written for the webview applied to a backend that is not one. The quality picker froze on the first stream. `StreamQualityResponse::Native` carried only a position, so nothing replaced the selection the UI holds after a native quality change. The picker derives the rung in force from that selection's rendition, and a transcode always has a rendition — so the fallback that would have used the requested value was never reached. The stream changed and the menu did not. The native variant now carries the `StreamSelection` the backend opened, like the HTML5 variant already did. This was invisible on the desktop because the webview path replaces the selection as a side effect of reloading its element. It looked correct there for a reason that does not generalise. A quality change restarted playback from zero. The resume position came from `videoElement.currentTime`, which the frontend cannot supply on a native backend — there is no `<video>` element, so it correctly sends null and the backend substituted 0. Reading it from the DOM at all inverts the rule that the player is the authority on playback state; the fallback now asks the controller where it is. Captured before the negotiation round-trip, so it resumes a few hundred milliseconds behind rather than ahead, which is the right direction to err. Also from the tablet, and NOT fixed here because it changes playback behaviour and deserves its own change: `audio_forces_transcode` judges against `WEBVIEW_AUDIO_CODECS` on every platform, and `video_audio_codecs` narrows the advertised direct-play audio set to that same webview list. On Android the decoder is ExoPlayer. The tablet reports dts among its platform codecs, has it stripped from the profile, and then has the webview rule force a transcode for it. That is the third instance of a decode capability tied to the wrong renderer, and it is what DR-233 exists to collapse — evidence now, not a design preference. It also corrects the record on this branch's headline number. The measured 85% direct-play rate used a hypothetical Android profile including ac3/eac3; this tablet's MediaCodecList reports neither, so eac3 content — about a third of the sampled library — correctly transcodes here. 85% was the ceiling of a profile the app does not send, on hardware that could not use it. The negotiation and the contract are sound; the figure was not a measurement of what ships.	2026-08-22 13:45:03 +02:00
dtourolle	84cf31b929	feat(video): build the native video surface, and fix what running it exposed ... Three things, all found by actually running the app rather than by reading it. The surface (DR-230). A GtkGLArea as the main child of a GtkOverlay with Tauri's own webview reparented on top — the desktop shape of what Android already does with ExoPlayer. It attaches cleanly and is then **off by default**, because the reparent fails the gate the spike said it would. `tauri-runtime-wry`'s undecorated-resizing handler walks a hard-coded path on every button press in the webview: webview.parent() // "This one should be GtkBox" .parent() // ...and this one the GtkWindow .downcast::<gtk::Window>().unwrap() Wrapping the webview makes that chain webview -> GtkOverlay -> GtkBox, the downcast fails, and the panic is non-unwinding so it aborts the process. The decoration check that would make the handler inert runs *after* the unwrap, so no window configuration avoids it. The surface attaching successfully is therefore not the gate — a click is. It lives behind JELLYTAU_NATIVE_VIDEO=1 with the mechanism written down, because the next attempt needs to keep Tauri's two-hop shape intact and that is the whole design constraint. Also settles a dependency question the spike left implied: the render API is reachable from the pinned libmpv revision. Its safe `render` module is an empty stub, but libmpv-sys carries every render symbol and `Mpv::ctx` is public, so the context can be built over the handle the audio backend already drives. This does not need the libmpv2 migration first. The HLS effect re-ran on object identity. `currentSelection` is a struct, and every reload replaces it even when the URL and transport are unchanged — so the effect tore down hls.js and reattached for an unchanged stream, leaving the element blank until a seek forced another cycle. The pre-DR-224 code read a plain URL *string*, where re-assigning the same value was a no-op; the codebase documents relying on that and swapping in a struct broke it silently. The loader decision now takes a primitive transport tag, so the component cannot depend on object identity — the bug is unrepresentable rather than merely fixed. The device profile contradicted itself. The direct-play profile claimed h264 alone on the webview path while the transcoding profile said "you may transcode to h264 or hevc" — telling the server "I cannot play hevc, so re-encode it" and then "re-encoding it to hevc is fine". Streams came back carrying VideoCodec=h264,hevc with hevc-level/profile/bitdepth set. When the server took that option the webview got something it could not decode, which presents as video stuck on its first frame rather than as an error. Transcode targets are now derived from the same codec list as direct play, capped to the two codecs a Jellyfin server actually encodes so a wider decode list never asks for an av1 encode. That is the third defect in one family: a decode capability stated in more than one place, with the copies disagreeing. DR-233 exists to collapse them into one renderer-derived source, and this is evidence for it rather than a preference. Not fixed here, and worth knowing: - The requested VideoBitrate is sized to the ceiling, not to the source — a 2.2 Mbps source was being re-encoded at 19.8 Mbps, roughly 9x. Pre-existing, but this branch is the first thing that knows the source bitrate and so the first that can cap it. - The `debug` build type produces an APK with the *release* applicationId: `applicationIdSuffix = ".debug"` is present in the canonical gradle and absent from the generated copy, though the identical line in the `release` block survives. Not caused by our sync, which is a plain cp. Independent of this work; it is why the side-by-side release build is the one that installs.	2026-08-22 13:45:03 +02:00
dtourolle	7cc392d78f	docs(specs): mpv draws desktop video, and the webview path goes ... The spike proved compositing works on Linux, including Wayland, and left two blockers. One is now closed: DR-228 measured a single EXT-X-STREAM-INF in the server's master playlist, so there is no adaptive bitrate for mpv to lose and finding 3 of playback-backend-unification.md is false. The spike is updated to record that. The other — an unexplained SIGSEGV in a decoder thread — is carried into the spec as DR-231 rather than chased: the spike had no render-context teardown at all, which is DR-184 on Android restated, and removing the likeliest cause is worth doing whether or not it was the cause. The spec targets every desktop platform rather than Linux alone, because the maintenance argument runs the other way. Video has three renderers today. A Linux-only version makes it four, permanently — mpv on Linux, HTML5 on Windows, ExoPlayer on Android, hls.js underneath — and the webview path then survives indefinitely because something still needs it. Finishing the job leaves mpv on desktop and ExoPlayer on Android, and hls.js, html5Adapter.ts, videoLoaderFor and the <video> element are deleted in a phase that has its own acceptance criterion so it cannot quietly become "later". The load-bearing change is DR-233: the device profile stops being a compile-time platform constant and becomes a property of the renderer that will decode the stream. The measured 7% desktop direct-play rate and Android's 85% differ by nothing except which component decodes, so that one change is what converts the former toward the latter. It looks like configuration and is not — it decides whether the server re-encodes, and it fails silently when wrong. Windows is costed rather than waved at: the surface is genuinely different code (WebView2 in an HWND, not GTK), but everything else is shared, so nothing may be guarded on cfg!(target_os = "linux"). The real cost is build — libmpv is a Linux-only dependency while Windows cross-compiles via cargo-xwin, so a Windows libmpv must reach that build and ship in the NSIS bundle under the LGPL terms DR-216 already records. Allocates UR-080, DR-230..236, IR-033. No product code yet.	2026-08-22 13:45:03 +02:00
dtourolle	109700b949	feat(playback): let Rust decide what stream to play, and say so ... Playing a video meant asking the server to re-encode it, always. That decision was made nowhere and written down nowhere, so whoever needed it re-derived it downstream — the player worked out whether it had been handed a playlist by looking for ".m3u8" in the URL, in two places. A viewer paid for a transcode of a file their device could have played untouched, and the app could not tell them which it was. One negotiation now produces one self-describing StreamSelection — direct play, remux or transcode; over a playlist, a plain HTTP file, or a local one — and every renderer consumes that same answer. Measured against the development server (Jellyfin 10.11.5), 400 items sampled for codec mix and 40 put through a real PlaybackInfo negotiation per profile: Linux / WebKitGTK (h264 only, 2ch) 3/40 — 7% direct play Android / ExoPlayer (hevc, ac3/eac3, 6ch) 34/40 — 85% direct play The library is ~80% hevc, which is why the two diverge so hard. The payoff is overwhelmingly Android, where 85% of plays were starting a transcode nobody needed. Linux stays near 7% until libmpv decodes the picture — the h264-only profile is a WebKitGTK constraint, not a JellyTau choice. DR-219 StreamSelection: url + tagged Transport (hls/progressive/localFile) + PlaybackKind (directPlay/directStream/transcode) + the negotiated rendition + this source's ladder + a needs_transcoding flag derived in Rust so the rule is answered once. Both enums are serde-tagged so the frontend matches a discriminant, not a substring. The paths that never negotiate get the same shape from Rust rather than assembling one — media_local_selection for a downloaded file, LiveStreamInfo.transport for a live channel — so there is no second place where a transport is decided. DR-220 The ceiling becomes two levels: a durable device default (Settings, persisted) and a per-playback override the in-player picker sets. The picker had called itself a "this film, this connection" control since it was written but wrote the process-wide default, so dropping one awkward film to 2 Mbps silently capped every video played afterwards for the rest of the process, with Settings still showing the old value. The override is cleared whenever playback moves to a new item, which stops it surviving into an autoplayed next episode. effective_streaming_quality() is the single resolution point. DR-221 The quality picker is filled from what this media source can offer. Rust marks a rung exceeds_source when its ceiling is at or above the source's own bitrate — such a rung is another way to spell Original — and the frontend does not draw those. Original is never marked; a source whose bitrate the server does not report marks nothing, which keeps every rung offered. DR-222 Direct play and direct stream are negotiated, with two client-side overrides on top because the server's answer is right about the file and wrong about what this app will do with it: undecodable audio (Jellyfin 10.11.5 honours a DirectPlayProfile's container and video codec but ignores its audio codec, so it offers direct play for an E-AC-3 track the webview renders in silence) and a viewer-pinned audio track the file does not default to. A direct stream is a remux and is deliberately not counted as transcoding. DR-223 Dropped on measurement, not deferred. A master playlist from this server carries exactly one EXT-X-STREAM-INF: Jellyfin builds it from the single rendition the request asked for rather than publishing a ladder. So there is no adaptation for hls.js to be preserving and none mpv would lose — the claim that there was, in playback-backend-unification.md, does not hold. Recorded rather than deleted because it is a measurement: a server that does publish a ladder would change the answer. DR-224 Every backend consumes the same selection. The queue item carries the transport, so player_seek_video picks its seek strategy from the backend's decision instead of the last stream_url.contains(".m3u8") in the codebase. Items queued by a path that never negotiated carry None and fall back to needs_transcoding, which is exact rather than a guess because every transcode this app requests is HLS (DR-140). The frontend loader decision moves to streamTransport.ts so it can be tested: the two cases that pin it are the ones that failed against the old implementation — a progressive stream whose URL contains ".m3u8" must not get an HLS loader, and an HLS stream whose URL contains none must. Also verified the URL the direct-play branch builds actually serves playable bytes: 206, video/mp4, valid ISO-BMFF, and a mid-file range works, so seeking a direct play works. The spec is folded into docs/architecture/{01,02,03} and deleted, per the rule that docs/specs holds only work that has not shipped. DR-121 leaves read-through-media-cache.md with a pointer; that spec keeps its capture half. Not verified: real playback on a device. Direct play changes what actually gets played, and neither fixtures nor curl prove the WebKitGTK and ExoPlayer paths render it.	2026-08-22 13:45:03 +02:00
dtourolle	5fede123e7	fix(deps): take the patched quick-xml via plist 1.10 ... cargo-deny went red on master with two quick-xml DoS advisories (RUSTSEC-2026-0194, RUSTSEC-2026-0195). They were absent before, and correctly so: quick-xml reached the graph only through plist on Apple targets, and deny.toml scopes the graph to the targets this project actually ships. The Tauri 2.11 upgrade changed that. plist is now pulled in by tauri-utils, which is a build-dependency of tauri-build, so it compiles on every target including Linux and the advisory became genuinely in scope. That is the gate behaving as designed -- silent while the crate was unreachable, loud the moment a dependency upgrade brought it into a build we ship. Fixed rather than ignored. plist 1.10.0 requires quick-xml ^0.41.0, which carries both patches, and tauri-utils accepts plist ^1, so the upgrade is a lockfile change with nothing else moving: plist 1.8.0 -> 1.10.0 quick-xml 0.38.4 -> 0.41.0 An ignore entry would have been easy to justify here -- build-time only, parsing files we generate, absent from every shipped binary -- and that is exactly why it would have been wrong: the justification would have outlived the reason for it, and the entry would still be sitting in deny.toml long after the upgrade became available. No release. quick-xml is a build dependency, so it is not inside any v0.10.1 artifact; this only restores master to green. Verified: cargo deny (advisories, bans, licences, sources all ok), cargo check, 765 tests, cargo fmt --check, clippy -D warnings.	2026-08-22 11:49:16 +02:00
dtourolle	edff6eedc9	fix(player): let the background-audio toggle govern backgrounding again ... Locking the screen kept a video's audio playing whether or not the background-audio button was on. Reported as "audio only mode is always active even if not selected". The button (UR-040) was built for the WebView <video> path, where losing visibility kills the decode: it chose between handing off to a native audio stream and letting playback stop. Native video then became the default renderer (DR-188), and on that path playback runs through ExoPlayer inside a MediaSessionService -- a foreground media service whose entire purpose is to keep playing while the app is hidden. Nothing stopped it, and nothing in the codebase paused on background. So the button governed a handoff that no longer had a gap to bridge. There was no interruption to paper over, and a user who never touched it got background playback anyway. The gating made it self-concealing: MainActivity.onStop only dispatched 'jellytau-background' when backgroundAudioEnabled was already true. The one notification that the app had gone away was itself conditional on the setting, so with the button OFF nothing could react even in principle. onStop and onStart now fire unconditionally and carry the two facts only the activity knows -- whether the toggle is armed, and whether Android put the window into picture-in-picture. What to do about it is decided in Rust (player/background_policy.rs), because it depends on whether the item has a picture to lose: video + toggle off -> Pause video + toggle on -> HandOffToAudio music, either -> KeepPlaying (no picture to give up) picture-in-picture -> KeepPlaying (the window is still on screen) It takes no renderer parameter on purpose. Two renderers with two behaviours and one toggle reaching only one of them is what produced the defect; a rule that cannot see the renderer cannot reproduce it. Two failure modes are deliberate. A decision call that fails leaves playback alone rather than risking silence mid-listen. An event with no detail -- older Kotlin against newer JS -- reads as "armed, not PiP", degrading to the previous behaviour instead of pausing unexpectedly. Foregrounding resumes only what backgrounding paused: a video the user paused themselves before locking stays paused. Written test-first per CLAUDE.md. The stub encoded today's behaviour (nothing ever pauses) and failed exactly as reported -- `left: KeepPlaying, right: Pause` -- before the rule was implemented. Verified on a device, R8-minified, both directions: [player_background_action] video=true armed=false pip=false -> Pause [player_background_action] video=true armed=true pip=false -> HandOffToAudio UR-040 / DR-224 / UT-211.	2026-08-22 10:09:46 +02:00
dtourolle	9c75e74ea3	fix(ci): give the builder image what linuxdeploy needs for the AppImage ... The v0.10.0 release build failed in Build Linux after 16 minutes: failed to bundle project: xdg-open binary not found /usr/bin/xdg-open: No such file or directory linuxdeploy embeds xdg-open into the AppImage and aborts the whole bundle when it is absent. deb and rpm had already bundled fine; only AppImage was affected. This is the one failure tonight that building locally could not have caught, and the reason is worth writing down: a developer machine is a desktop and always has xdg-utils, so the AppImage builds there and fails on a minimal server image. The asymmetry is the bug. Every other release defect this evening was found by building locally first; this one needed the runner. xdg-utils, desktop-file-utils and zsync are added together rather than one at a time. Each round trip costs an image rebuild plus a failed release build, and those three are what linuxdeploy commonly reaches for (xdg-open, desktop-file-validate, and zsync for delta updates). Workflows move to jellytau-builder:2026.08.1, built and pushed with all three verified present inside it before this commit. ci-operations.md gains two things learned here: that an apt addition invalidates the layer above the cargo-install steps, so it is a ~20 minute rebuild rather than the ~2 minutes the trailing layer normally gives; and that Tauri's AppImage bundler downloads linuxdeploy, AppRun and two plugin scripts from GitHub during the build, so an AppImage build depends on GitHub being reachable from the runner.	2026-08-22 02:52:32 +02:00
dtourolle	76a2d9609b	fix(release): produce updater artifacts, and point the manifest at them ... Two defects on the release path, both of which would have failed the v0.10.0 build after all three platforms had already compiled -- caught by running a real signed build locally instead of waiting for the tag. **createUpdaterArtifacts was never set.** Without it Tauri emits only the plain .AppImage and .exe: no signatures at all. The manifest step then finds none and aborts by design, so the release dies at Create Release having spent ~40 minutes building artifacts it cannot publish. **The manifest looked for the wrong filename.** Tauri v2 signs the .AppImage *itself* and writes <name>.AppImage.sig beside it. The .AppImage.tar.gz form this workflow globbed for only exists under createUpdaterArtifacts: "v1Compatible". A real signed build produced: 154M JellyTau_0.10.0_amd64.AppImage 420 JellyTau_0.10.0_amd64.AppImage.sig so the glob would have matched nothing and the step would have aborted for a second, entirely different reason. Both the artifact collection and the manifest now use the v2 names, and the AppImage and its .sig ship together -- a manifest referencing a signature that was never uploaded fails only on the user's machine. Verified before tagging rather than after: the manifest logic was run against the real artifacts (420-char minisign signature read correctly) and the resulting latest.json checked for validity and shape. The Windows side already used the correct pattern (<installer>.exe.sig), which is why only Linux needed the change.	2026-08-21 23:14:16 +02:00
dtourolle	30a9cb32f5	chore(release): v0.10.0 ... Two user-visible features -- the app can update itself, and it can hand you a redacted diagnostics bundle -- plus the supply-chain, release integrity and build work behind them. A minor bump rather than a patch, matching how v0.9.0 was cut off v0.8.2 for a single new user requirement. This one carries two (UR-077, UR-078), both with UI in Settings. The CHANGELOG entry is the release body now: build-release.yml publishes the `## v0.10.0` section and fails if it is missing, instead of the fixed block of install instructions that every release from v0.0.1 to v0.9.1 carried verbatim.	2026-08-21 22:32:04 +02:00
dtourolle	88260ab6c9	Merge pull request 'Fix release notes and stop shipping stale installers' (#16) from fix/release-artifacts-and-notes into master	2026-08-21 20:30:54 +00:00
dtourolle	214997144f	feat(deps): upgrade Tauri to 2.11.5, and own the Android context it stopped setting ... The plugin versions could not be matched upward without this: both tauri-plugin-log 2.9.0 and tauri-plugin-updater 2.10.1 require tauri ^2.10, and the tree was on 2.9.5. So the framework moves with them -- tauri 2.9.5 -> 2.11.5, tauri-build 2.5.3 -> 2.6.3, wry 0.53.5 -> 0.55.1 -- and every plugin's Rust crate and npm package is now pinned to the same version on both sides. That upgrade broke Android outright, and the breakage is the interesting part. Seven call sites in this crate reach JNI through ndk_context::android_context(), which reads a process-global pair of pointers. Nothing here ever set that global. `tao` did -- the windowing layer under wry, three levels below anything this project names in Cargo.toml. tao 0.34.5 called initialize_android_context() while starting the activity and our code read what it left behind. tao 0.35.3 keeps the same two pointers in a private struct and no longer publishes them. The result, on every launch, was: PANIC at ndk-context/src/lib.rs:72: android context was not initialized 8: ndk_context::android_context 9: jellytau_lib::run::{{closure}} Not a crash in our code, and not a change to our code: an undocumented side effect of a transitive dependency disappeared. Relying on someone else to populate a global is a dependency that does not appear in Cargo.toml and gives no warning when it goes. src-tauri/src/android_context.rs now owns that invariant instead of assuming it. JNI_OnLoad captures the JavaVM as the shared library loads -- the earliest moment available, and nothing in tao, wry or tauri defines one to collide with. The Context is resolved lazily via ActivityThread.currentApplication() and pinned as a global reference for the process lifetime, since ndk_context stores a bare pointer and does not own it. It publishes the Application rather than the Activity: SecureStorage.initialize() immediately reduces its argument to applicationContext anyway, and an Application cannot outlive itself the way a retained Activity would. Restoring the global keeps all seven callers untouched. Threading a VM and Context handle through five credential call sites would have been a larger change with more risk, on the credential path. Failure now degrades instead of aborting: it is logged and credentials fall back to the encrypted-file path, which the app already supports. Verified on a device, R8-minified, not merely compiled: [INIT] Android JavaVM and Application published to ndk_context Android SecureStorage initialized successfully Android Keystore available via SecureStorage [INIT] Using system keyring for credential storage [CodecDetection] Detected 7 video codecs: av1,h263,h264,hevc,... -- the real keystore path, not the fallback, and the app stays up. None of this is reachable by CI: nothing there runs the app. Also fixed here, both found the same way: - `tauri android build --apk true` is now `--apk`. The CLI took a value until 2.10; from 2.11 the stray `true` is a positional and the build fails before starting. Three call sites in build-android.sh and one in build-release.yml -- the latter builds the signed APK, by far the most-downloaded artifact. - scripts/build-android.sh ran `npm install` on its clean-build path in a bun project, ignoring bun.lock and re-resolving the tree. That is exactly how the plugin crate/package versions drift apart again. scripts/check-tooling.sh now fails on any npm/yarn/pnpm invocation or foreign lockfile, and runs in CI. DR-222, DR-223.	2026-08-21 22:30:28 +02:00
dtourolle	9a19d30e6c	fix(build): make the release actually buildable, and check it before tagging ... Preparing v0.10.0 meant building the release locally first. It did not build. Two separate defects were sitting on master, both invisible to every gate this project has, for the same reason: nothing in build-and-test.yml runs `tauri build`. Only a tag does. So the first time anyone would have discovered either was a failed release. **Tauri plugin versions had drifted apart.** Tauri refuses to build when a plugin's Rust crate and npm package are on different minor versions: tauri-plugin-log (v2.8.0) : @tauri-apps/plugin-log (v2.9.0) tauri-plugin-updater (v2.9.0) : @tauri-apps/plugin-updater (v2.10.1) Introduced by the updater and diagnostics work in this same branch -- `cargo add` took what the pinned toolchain allowed while `bun add` took latest, and the caret ranges let them separate. cargo check, clippy, cargo test and svelte-check all passed. Matching upward pulled wry 0.53.5 -> 0.54.2 along with wasm-bindgen, web-sys and webkit2gtk: the webview layer, which on Linux is the video playback path. That is not a change to make while cutting a release, so the npm packages are pinned down to the crates instead -- exactly, not by caret, since the caret is what allowed the drift. The upgrade is worth doing deliberately, with a playback check, and ci-operations.md says so. CI now runs `tauri info`, which performs the same comparison without building. Verified by reintroducing the mismatch and watching it fail. **The AppImage target had never been built.** It was added earlier in this branch because the release notes had advertised an AppImage for months while tauri.conf.json never produced one. It does not work out of the box: linuxdeploy carries its own `strip`, too old to parse the .relr.dyn section modern toolchains emit, and it fails on every bundled library -- strip: libzstd.so.1: unknown type [0x13] section `.relr.dyn' failed to bundle project `failed to run linuxdeploy` Ubuntu 23.10+ links with -z pack-relative-relocs by default, so the CI builder image fails exactly as a modern Arch host does. NO_STRIP=true is linuxdeploy's documented escape hatch. The resulting 153 MB AppImage was verified to be well-formed and to actually start. Without this the release would have failed at the Linux build step -- the artifact check added earlier refuses to publish when no AppImage is produced, which is the behaviour we want, but it would have refused a tagged build rather than a local one. Also: the traceability extractor now reads the tooling shell scripts that carry TRACES comments. DR-207, DR-213 and DR-220 all had them and were counted as uncovered because only .ts/.svelte/.rs were scanned. Listed individually rather than globbing scripts/*.sh -- most implement nothing, and adding one should be a decision. DR-221.	2026-08-21 20:22:12 +02:00
dtourolle	5d02628689	fix(release): publish real notes, and stop shipping old releases' installers ... Two defects found while preparing v0.9.2, both of which had been shipping for months without anything to notice them by. **Every release note was the same 1,050 bytes.** All 35 releases from v0.0.1 to v0.9.1 published identical generic install instructions whose "What's New" section read "See CHANGELOG.md" -- a link that does not resolve from a release page. A reader learned nothing about what changed in any release the project has ever made. The body now comes from the `## <version>` section of CHANGELOG.md, and a missing section fails the release: notes that say nothing are worse than a build that waits for a maintainer to write two sentences. The 35 published bodies have been backfilled from the changelog via the tea CLI. This also corrects something introduced two commits ago. That change generated the body from `bun run release:notes`, which CLAUDE.md is explicit about -- its output is "a reviewed draft, not a final changelog". Publishing it unreviewed proved the point immediately: the v0.9.1..HEAD range contains a repo-wide prettier sweep, so every file in src/ counted as changed, their TRACES resolved to nearly the whole matrix, and the draft claimed the release had added the entire application. The script now skips cosmetic commits (chore(format), chore(deps), style) and reports how many rather than silently returning a smaller set, but it stays a local drafting tool. **Every release from v0.1.0 to v0.8.2 shipped every Windows installer ever built.** src-tauri/target/*/release/bundle/ is not versioned, cargo never cleans it, and the runner reuses the target directory -- so the copy step's bundle/**/*-setup.exe glob collected the lot. v0.8.2 carried sixteen installers, thirteen of them stale; v0.5.0 offered users a download list going back to 0.1.0. Eight months, and nothing to notice it by: the upload loop reported success, the files were real, and the page looked busy rather than wrong. It stopped only because an unrelated cargo cache change wiped the runner's target dir, so it was dormant, not fixed. Both desktop builds now remove the bundle directory before building, so a stale file cannot exist to be copied. Filtering the copy by version would have hidden it instead. The Linux job gets the same treatment: it was never hit only because Linux packaging is newer, and the glob is identical. scripts/check-release-artifacts.sh is the backstop for whatever reintroduces one by a route nobody predicted. It runs before the SBOM, the checksums and the upload -- all of which describe the file set, so a stale artifact has to be caught before it is hashed and published as part of the release. Verified against a reconstruction of the real v0.8.2 accumulation. DR-219, DR-220, UT-210.	2026-08-21 19:54:46 +02:00
dtourolle	cac9afa6bd	Merge pull request 'Chore/infra hardening' (#15) from chore/infra-hardening into master ... Reviewed-on: #15	2026-08-21 17:44:48 +00:00
dtourolle	2e3a864ef0	Merge branch 'master' into chore/infra-hardening	2026-08-21 17:44:27 +00:00
dtourolle	1d56517f07	docs(specs): add backend-owned stream selection ... Rust becomes the single owner of which stream to play — direct play or transcode, at what ceiling, over what transport — and hands every player backend a self-describing StreamSelection instead of a bare URL. mpv, ExoPlayer and the HTML5/hls.js path all consume one decision rather than three places re-deriving it. The motivating leak is concrete. VideoPlayer.svelte determines transport with `currentStreamUrl.includes(".m3u8")`, in two places, for a URL Rust constructed and therefore already knows the shape of. That is the boundary rule in miniature: not item-type taxonomy, but the same error of reconstructing a domain fact in the presentation layer because the wire shape did not carry it. A tagged Transport enum deletes it. The design line, which ExoPlayer forces: Rust decides *what stream*, the player decides *how to deliver it*. ExoPlayer has genuine adaptive track selection; this spec must not reimplement or fight it. Rust only adapts where the player cannot (mpv) and the server actually offers a ladder. Six phases, and phase 1 stands alone as pure ownership movement with no behaviour change. Phase 4 (direct-play negotiation) is what removes the transcode and unblocks the Linux native-video work. Phase 5 (adaptation) is gated on counting EXT-X-STREAM-INF entries in a real playlist — the acceptance criteria require that count be recorded before it is either started or dropped. Takes DR-121 from read-through-media-cache.md, which specced Rust-owned quality reporting but never built it; that spec keeps its capture half.	2026-08-21 19:41:32 +02:00
dtourolle	99d96163d8	docs(specs): correct the spike's crash and ABR findings ... Three corrections to the Linux native-video spike, each of which reverses something recorded earlier in the same session: - The crash is unexplained. It was first blamed on hwdec=auto-safe's Vulkan failures, on a misreading of the logs — those are two per run at start-up, not per-frame, and every clean run has the same two. A 300s soak on auto-safe survived. So did 240s of automated fullscreen toggling (~120 transitions) and 240s of continuous resizing (~2000 reallocations). Three hypotheses, none reproduced. Recorded rather than dismissed: an intermittent fault nobody can reproduce is worse to inherit than a deterministic one. - G5 drops to amber. It looked and felt smooth, but the only SIGSEGV observed came from the only session in which fullscreen was exercised, and the spike has no lifecycle handling at all — it never frees the render context. An implementation must bind that to the GL context's lifetime regardless of what caused this crash, because Android already paid for that lesson as DR-184. - Finding 3's premise is in doubt. "The webview path already has real ABR via hls.js" was never checked against the URLs this app builds: get_video_stream_url requests a single rendition, the frontend has no level-handling code at all, and a quality switch is implemented by re-opening the stream. If the playlist is single-variant there is no adaptation to lose. The decisive test needs a live server and is recorded as unrun. Also records hardware decode working through the render API (nvdec-copy engaged), and that hwdec=vaapi silently fell back to software on this box.	2026-08-21 19:41:21 +02:00
dtourolle	eda6e36d3d	Merge pull request 'Infrastructure hardening: CI enforcement, supply chain, updater, diagnostics' (#14) from chore/infra-hardening into master ... Reviewed-on: #14	2026-08-21 17:33:53 +00:00
dtourolle	f11f5eddd5	docs(specs): record the Linux native-video compositing spike ... Adds the spike write-up and re-opens finding 2 of playback-backend-unification.md, which concluded that video cannot unify on a native engine because the webview owns the surface. That finding's general form has since been falsified on Android, where native video composites behind a transparent WebView and ships on by default. The evidence behind it was also entirely about foreign-window embedding -- mpv's render API, drawing into a GL context we own inside Tauri's own GTK tree, was never tested. The spike tests that one claim and comes back green on Linux for both X11 and Wayland, bar the Tauri default_vbox() half of G1. Findings 3-6 are deliberately left standing. Finding 3 in particular -- mpv has no adaptive bitrate -- is an independent disqualifier that a green compositing result does not clear, and the spike says so rather than reading as a green light. The next-free-id line moves to UR-079 / IR-033 / DR-219: this branch allocated UR-077 and UR-078 for the updater and diagnostics work, and DR-215 through DR-218 with them, after that line was last written. Authored in a parallel session working in the same checkout; committed here so it travels with the rest of the branch.	2026-08-21 19:06:13 +02:00
dtourolle	f3fa45f742	feat(diagnostics): persistent redacted logging and an exportable bundle ... The app forgot everything it did the moment it exited. The Rust half logged through env_logger to stdout only -- invisible to anyone who launched from a desktop icon, and on Android worse than that: stdout is not logcat, so the backend produced no visible output at all on the platform carrying this project's hardest bugs. The autoplay deadlock, the truncated-stream restart and the background-audio stall were all diagnosed by talking a user through `adb logcat`, because there was no other way to see anything. A panic left nothing behind at all. Logs now go to a size-capped rotating file, to logcat on Android, and to the webview console in dev. A panic is recorded with its backtrace before the process dies. The frontend's messages are forwarded into the same file, so one timeline holds both halves of the app in order -- which is what makes a race between them legible after the fact, and races between them are the expensive bug class here. Redaction runs in the log FORMATTER, not at export time. A credential sitting in a file on the device is already a disclosure; stripping it on the way out would be too late. The exporter redacts a second time to cover files written by builds that predate this. api_key, X-Emby-Token, Authorization, "AccessToken" and Token="..." all reduce to [REDACTED], while host, item ids and filenames are deliberately kept -- a log scrubbed of those is one nobody can debug anything from. Server URLs keep scheme and host and drop any embedded user:pass@. Two things the tests caught that review would not have: - redact_headers recursed on its own output. The replacement keeps the header NAME, so the next call matched the same header forever; the test died with a stack overflow. It is a forward scan now. - The frontend forwarder used `void plugin.error(...)`. `void` discards a promise's value but not its rejection, so in any webview without IPC -- a unit test, SSR, a browser preview -- every log line became an unhandled rejection. 20 of them showed up the first time coverage ran. Each call now attaches a catch. Only info and above cross the IPC boundary: debug is per-tick player state and forwarding it would be thousands of calls a minute for output nobody reads. A failing forwarder never propagates and never prevents the console write. Nothing is transmitted anywhere. The export writes a zip and reports its path; the user attaches it themselves, which is also what keeps this from becoming telemetry. An Android share intent is explicitly out of scope -- it is Kotlin work that belongs with the other native code. The panic hook chains to the previous hook rather than replacing it, because utils/lock.rs installs a silencing hook around tests that provoke poisoned locks on purpose. Spec in docs/specs/diagnostics-and-logging.md; UR-078 / DR-218 / UT-209. Verified: 1079 frontend tests and the coverage gate, 759 Rust tests, clippy -D warnings, svelte-check 0 errors, and cargo check for aarch64-linux-android.	2026-08-21 18:58:57 +02:00
dtourolle	fb72bf3005	docs(ci): drop the runner-health references the amend missed ... The commit that removed .gitea/workflows/runner-health.yml was amended with a git add whose pathspec named the already-deleted file, so the add aborted and only the deletion was staged -- leaving ci-operations.md still describing a scheduled job that no longer exists. The runner section now says what to check by hand and why there is no job: on a single-slot runner a daily job takes the slot and pulls the builder image to run df, and df inside a container does not reliably describe the host disk.	2026-08-21 18:58:39 +02:00
dtourolle	6897b290ed	docs: add the governance and CI-operations files the project never had ... The repo had no SECURITY.md, CONTRIBUTING.md, code of conduct, or issue and PR templates. For a client that handles Jellyfin credentials and ships signed binaries, the missing one that actually matters is SECURITY.md: there was no stated way to report a vulnerability privately, so the only available channel was the public tracker. CONTRIBUTING.md documents the gates as they now stand, including the three ratchets and which direction each is allowed to move, and the two rules that surprise people: bug fixes start with a failing test, and Jellyfin's taxonomy stays in Rust. The bug template asks the three playback questions -- streaming or downloaded, transcoding or direct, music or video -- because those answers decide which of several very different code paths a report is about, and reconstructing them over several round trips is most of the cost of a playback bug report. docs/build/ci-operations.md is the missing operations manual: how to change the builder image and in what order (image pushed before the workflow that names it, or CI breaks), why tags are dated rather than :latest or per-SHA, what each secret is for, and what losing the updater private key would mean -- installed desktop clients only accept payloads signed by the key matching the public key they shipped with, so losing it means everyone reinstalls by hand. Disk exhaustion on the runner is documented as a manual check rather than a scheduled job. A daily job would occupy the only slot on a single-slot runner and pull the whole builder image to run `df` -- and `df` inside a container does not reliably describe the host's disk, so it would spend real build capacity reporting a number that might be wrong. What the doc records instead is the part that is actually hard to rediscover: the symptoms (cargo dying mid-link, docker refusing to pull, actions/cache quietly not saving) and that `docker volume prune` needs `-a` to touch named volumes, which is how it filled up unnoticed. Two things in these docs are stated plainly because they are true and were not written down anywhere: without branch protection every gate in the pipeline is advisory, and the Gitea instance -- canonical remote, signing secrets, registry, runner -- is not backed up by anything in this repository.	2026-08-21 18:45:40 +02:00
dtourolle	3211c96ecf	feat(updater): in-app update on desktop, releases link on Android ... Anyone who installed an AppImage or ran the Windows installer was frozen on that version forever. Nothing in the app ever mentioned a new release existed, and the release notes were the only announcement. Desktop now checks a signed manifest, shows the version and its notes in Settings, and installs and relaunches on request. The signature check is the whole point: it is what stops a substituted download from being installed by the app itself. Windows binaries stay unsigned for SmartScreen purposes -- that is a code-signing certificate, a separate problem -- but the update payload is verified against our own key. Android is deliberately not wired to the updater. An app may not replace its own APK; that is the package installer's job, and the plugin has no Android implementation. It gets a link to the releases page instead of a button that would throw. The plugins are gated with a target-triple cfg rather than cfg(desktop). Cargo only evaluates target cfgs in a [target.'cfg(..)'] table, so cfg(desktop) matches nothing, silently drops the dependency, and fails much later with "Permission updater:default not found" -- which is exactly what the first attempt here did. Where the manifest lives took some finding. This Gitea serves /releases/download/<tag>/<asset> but 404s on /releases/latest/download/<asset> (verified against a real asset), so there is no stable latest-release URL. The gitea-pages branch is force-pushed wholesale by publish-docs.yml, so it cannot host the file either. latest.json therefore gets its own orphan branch, read over the raw-file URL, and is published from a scratch repo in RUNNER_TEMP rather than by switching branches in the checkout -- doing that would have left the following steps standing on a one-commit history, and the next step but one runs release:notes against the real commit range. Also fixed, all of it release-integrity: - "appimage" is in bundle.targets. The release notes have advertised an AppImage for months; tauri.conf.json never built one, the artifact step globbed for *.AppImage, found nothing, and said nothing. The step now fails instead. - The .AppImage.tar.gz/.sig pair and the NSIS .sig are collected. A manifest referencing a signature that was never uploaded fails only on the user's machine, so the manifest step also refuses to write an entry with an empty signature. - Release notes are generated by release:notes from the traceability graph, which is what CLAUDE.md has asked for all along, instead of a fixed heredoc that said "see CHANGELOG.md for detailed changes" and linked "GitHub Issues" on a Gitea-hosted project. - The notes tell users how to verify a download with SHA256SUMS. Requirements UR-077 / DR-217, tests UT-208 (12 cases over the version comparison and the platform decision, including that a pre-release does not offer itself as an upgrade to the matching release). Verified: 1070 frontend tests, cargo check for both the host and aarch64-linux-android (confirming the plugins are absent there), clippy -D warnings, svelte-check 0 errors.	2026-08-21 18:41:50 +02:00
dtourolle	96abc3afef	docs(specs): make "a spec becomes an architecture doc" the written rule ... The sixteen specs folded in last commit were folded because someone noticed they had gone stale, not because anything said they should be. Without the rule written down the directory drifts straight back to a mix of promises and descriptions, and neither can be trusted: you cannot tell from a file whether it describes the build or proposes a change to it. So: docs/specs/ holds only unshipped work, there is no "Implemented" resting state, and the fold-in and the deletion happen in the same commit. The template now asks for the destination architecture doc **up front**, which is a design check rather than bookkeeping — a feature that fits no existing doc usually has an unclear layer assignment, and it is cheaper to find that out at spec time. It also tells the author which half of what they are writing is durable (invariants, rejected alternatives, the defect a decision prevents) and which half dies with the file (phases, migration steps, acceptance criteria). The review checklist gains a Lifecycle section, including the case that gets lost otherwise: out-of-scope work worth doing has to be written where it will still be found after the spec is gone.	2026-08-21 18:29:09 +02:00
dtourolle	f6653e6a8b	ci(security): add a supply-chain gate, checksums and an SBOM ... The project shipped signed Android builds and unsigned desktop binaries with no vulnerability scanning of any kind. Nothing checked the ~500 crate Rust graph or the JS packages against an advisory feed, and nothing checked that what we redistribute inside an MIT bundle permits it. The first cargo-deny run found eight vulnerabilities and one unsoundness -- bytes, four in rustls-webpki, time, two in quick-xml and rand -- every one of them closed by a `cargo update` nobody had a reason to run. That update is in this commit; 740 Rust tests and clippy -D warnings pass on the new lockfile. Two structural fixes matter as much as the gate itself: - deny.toml scopes the graph to the targets we actually ship. Without it the Apple targets pull in plist -> quick-xml and report two DoS advisories against a crate that is in no binary we release. Ignoring those by ID would silence them everywhere, including where they would matter; scoping makes them correctly absent. - libmpv is pinned by rev instead of branch = "master". A branch means the revision is whatever Cargo.lock happens to hold and any `cargo update` silently substitutes new upstream code -- in the one dependency that is not from crates.io and that links a C library into the player. The rev is the commit already locked, so this pins current behaviour rather than changing it. Licence findings are recorded rather than waved through. libmpv and libmpv-sys are LGPL-2.1, satisfied here by dynamic linking against the system library; deny.toml carries the two obligations that follow (keep the linkage dynamic, ship libmpv's licence text with any bundle carrying the .so). MPL-2.0 crates are file-level copyleft and fine unmodified. Releases now publish SHA256SUMS (verified in-job with `sha256sum -c` before upload) and a CycloneDX SBOM for both halves, so "does this release contain <vulnerable crate>?" has an answer that is not "rebuild the tag and re-resolve it". Workflows pin jellytau-builder:2026.08 instead of :latest. While every job said :latest, rebuilding the image changed what every build compiled against, including rebuilds of old release tags. Also folded in, because both were the same class of problem: - publish-docs.yml downloaded mdBook from GitHub releases into /usr/local/bin at job time -- a toolchain install in CI, which CLAUDE.md explicitly forbids, and a hard dependency on GitHub's CDN at publish time. It is in the builder image now. - extract-traces.ts only ever read .ts/.svelte/.rs, so every requirement implemented by *configuration* was invisible to the matrix that measures it. DR-205, DR-206, DR-207 and DR-215 all carry TRACES comments nothing read, and each counted as uncovered while being covered. Coverage was really 90%, not 88%; MIN_THRESHOLD moves to 89 accordingly. CI workflows stay excluded and there is a test saying why: traceability-check.yml quotes "a TRACES: comment" beside deliberately-undefined example IDs, which the extractor would read as real traces and then fail its own dangling-ID check. Supply-chain requirement is DR-216. 🔴 The builder image must be rebuilt and pushed (scripts/build-builder-image.sh 2026.08) before this reaches master -- the workflows now name a tag and tools that do not exist in the registry yet.	2026-08-21 18:25:38 +02:00
dtourolle	32043a2152	docs: fold shipped specs into the architecture docs and delete them ... A spec was a promise; sixteen of them had become descriptions of code that already shipped, sitting beside four that describe work still outstanding, with nothing in the file telling the two apart. Half the statuses were also wrong — audio-equalizer read "Accepted" with the EQ live on both platforms, the native video spec said the flag stays off after the default was flipped on. The shipped designs move into docs/architecture, which is the maintained description of the build, and the spec files go. Git history keeps the originals; what a future change still needs is carried across: - 01-rust-backend: favourites rewritten (the old section named a file that no longer exists and called shipped buttons "planned"), domain vocabulary owned by Rust (SearchScope, exclusions, the bitrate ladder), background workers - 02-svelte-frontend: app shell and chrome, library mosaic, series/episode navigation, downloaded browse, safe-area insets, native-video store, logging - 03-data-flow: locally-indexed search - 05-platform-backends: audio settings on ExoPlayer, the equalizer's band vocabulary, native video compositing, the background-audio handoff - 06-downloads-and-offline: one storage model, offline catalog visibility - 09-security: path confinement and input binding docs/specs/README.md now says what the directory is for and where each shipped design went. Deferred work the specs recorded is kept beside the code it concerns rather than lost: season-bounded autoplay, the two dead search commands, why indexing is a full crawl. requirements.md had fourteen stale statuses — Android audio parity still read "Linux only", DR-150 still said the native-video default was off, DR-190 was Proposed after DR-196 implemented it, and five tooling requirements were Proposed after landing. Three unbuilt specs suggested requirement ids that have since been allocated to other work; each now carries a warning.	2026-08-21 18:15:58 +02:00
dtourolle	8f5c9023d0	ci: make the frontend gates real, and fix the coverage script ... The repo configured four frontend gates and enforced one of them. eslint and prettier ran in no workflow and no hook; `bun run check` ran only in build-release.yml, so a type error could sit on master until somebody cut a tag; and `bun run test:coverage` had been dead for months. CI (build-and-test.yml) now runs format:check, lint, check and coverage alongside the existing boundary and doc-link tripwires. The coverage script failure was a version mismatch, not a config problem: @vitest/coverage-v8 resolved to 4.1.10, whose peer range pins vitest exactly, while package.json asked for ">=1.0.0 <5.0.0" and got 4.0.16 -- every run died on a missing BaseCoverageProvider export. The loose range is what allowed the pair to drift, so it is now ^4.1.10. Two ratchets, same policy as MIN_THRESHOLD in traceability-check.yml: eslint --max-warnings=159 (0 errors; 159 is today's backlog, only ever lower it) vitest thresholds (statements 51 / branches 45 / functions 46 / lines 52, measured at 54.6 / 48.7 / 49.6 / 55.1) no-console is promoted from "off" to "error": the logger-facade migration it was waiting on is finished -- 8 calls remained, 2 of them real stragglers in the settings page, now on the facade the file already imported. The sink itself, tests, and scripts/ are exempted; a CLI whose stdout is the product is not a stray debug statement. The threshold was verified to bite by raising it to 99 and watching the run go red, not by assuming an unfailed gate works. DR-205 moves to Done; the coverage gate is DR-215.	2026-08-21 18:11:26 +02:00
dtourolle	ad48d89dfe	chore(format): run prettier over src/ and scripts/ ... Formatting was configured but never enforced: `bun run format:check` reported 199 unformatted files and ran in no workflow and in no git hook, so .prettierrc (printWidth 100, trailing commas) described an intention rather than the tree. This is the one-time sweep that makes the check gateable. Whitespace and token-reflow only -- no behavioural change: `bun run check` reports 0 errors and all 1053 frontend tests pass before and after. Kept out of every other commit on purpose. A 199-file diff mixed with real changes is unreviewable, and the next commit turns format:check into a hard CI gate so this cannot silently accumulate again.	2026-08-21 17:41:44 +02:00
dtourolle	d095e1f410	fix(ci): drop the bash-only shopt from the Linux artifact step ... "Prepare Linux artifacts" ran `shopt -s nullglob`, but the runner executes `run:` blocks with POSIX sh, where shopt does not exist. It exited 127 and failed the step -- so build-linux never uploaded, create-release (which needs all three build jobs) never ran, and v0.9.0 and v0.9.1 both compiled successfully but published nothing. The last release with assets is v0.8.2. Reproduced under busybox sh: the current block prints "shopt: not found", passes the unmatched rpm glob through literally ("cp: can't stat '.../bundle/rpm/*.rpm'"), and exits 127. Without nullglob an unmatched pattern stays literal, so test each candidate with [ -e ] instead; the same input then exits 0 with the AppImage and deb copied. traceability-check.yml already carries this rule in two places (`case` instead of `[[ == ]]`, a pipe instead of a here-string). Keeping the fix POSIX rather than adding `shell: bash` follows that convention and drops the dependency on bash being present in the builder image.	2026-08-21 13:34:20 +02:00
dtourolle	a7365b9511	fix(ci): cache the cargo registry, not the 16 GB target dir ... The runner's 74 GB disk kept filling. Measured on the box: 24 GB of act cache, 23.18 GB of it created in 20 days -- ~1.15 GB/day against a 30-day-unused / 90-day-used GC, so it could never converge. Cause: src-tauri/target (16 GB locally: 9.6G debug, 3.2G release, 2.4G android) was cached under five separate keys, all keyed on hashFiles('**/Cargo.lock'). The release script stamps the version into Cargo.lock, so all five invalidated on every chore(release) -- 32 distinct lockfile revisions in three months. - Cache only registry/index, registry/cache and git/db. registry/src is omitted as well: cargo re-extracts it from the 155 MB of .crate tarballs rather than storing 1.1 GB extracted. - Collapse the five per-job keys into one shared cargo-registry key. They existed to keep debug/release target artifacts from clobbering each other; with target uncached, registry contents are target-independent and every job wants the same crates. - Split cargo-xwin into its own key. It tracks the xwin version in the builder image, not our lockfile, so keying it on Cargo.lock was re-downloading the whole Windows SDK on every release bump. - CARGO_INCREMENTAL=0: never reused across runs, 3.5 GB of the debug dir. - Installer artifact retention 30d -> 7d; tagged releases carry the binaries anyway. Inflow drops from ~5 GB to ~150 MB per lockfile change. Tradeoff: Rust jobs now compile cold every run (~31min vs ~9min on a cache hit for the Linux release build). Most runs already paid that, since a release bump invalidated every key. sccache with a hard size cap is the way back if it bites.	2026-08-21 11:59:28 +02:00
dtourolle	16658889a2	fix(home): restart the hero banner timer on a manual change ... The rotation interval was installed once when the banner mounted and never touched again, so a swipe, arrow or dot tap inherited whatever was left of the running countdown — swiping 5.5s into a 6s interval moved the banner on half a second later. The timer moves into heroRotation.ts as a small restartable object so it can be unit-tested, and every manual navigation path restarts it from that moment. Verified red-first: with restart() reverted to leave a running timer alone, the regression test fails. Release 0.9.1.	2026-08-20 23:11:30 +02:00
dtourolle	98b2ede8bd	fix(arch): build with custom-protocol so the package can load its own UI ... The PKGBUILD ran a bare `cargo build --release`. Without `--features tauri/custom-protocol` Tauri does not embed the frontend and serves it from devUrl instead, so the package compiled, linked, installed and passed every check — then launched into "Could not connect to localhost: Connection refused". `tauri build` passes that feature for you and the Android build passes it explicitly; this path never did, so the Arch package has never worked. Adds a check() that catches it at build time. It tests for the *assets*, not for the dev URL: devUrl is part of the config blob generate_context!() embeds either way, so grepping for it reports a failure on a correct build. A content-hashed filename from the vite output can only appear if the bundle was embedded — which is also why the fixed binary is ~400 KB larger. Found by installing the package and launching it, which is the only thing that would have found it.	2026-08-20 22:43:34 +02:00
dtourolle	38d56e6c89	fix(scripts): check links in tracked files, not everything on disk ... The prune list was wrong three times running: it walked the scratch worktrees under .claude/, then makepkg's vendored cargo registry under packaging/arch/src/, reporting a dependency's broken README as if it were ours. Every one of those directories is already git-ignored, so asking git for the file list makes the exclusion rule the same one the repo already maintains — and it cannot drift the way a hand-kept prune list did. It also makes the script do what its header always said it did: check tracked markdown. Untracked-but-unignored files are included on purpose, so a new doc is checked before it is committed rather than after. The find(1) path stays as a fallback for a non-git checkout. CI was unaffected — a fresh checkout has none of those directories — but the local gate cried wolf, which is how a gate stops being read.	2026-08-20 22:27:29 +02:00
dtourolle	4f4741cee5	fix(release): stamp the Arch package version, and ship the licence with it ... pkgver sat at 0.0.18 while the tree was on 0.8.x, because the Arch package is built by makepkg rather than the tauri bundler and set-version.sh never touched it. makepkg produced a package whose version bore no relation to the source it was built from — the exact failure that script exists to prevent, in the one file it had missed. Dev versions are converted to a pkgver Arch accepts: a hyphen separates pkgver from pkgrel, so 0.9.0-3-gabc1234 becomes 0.9.0.r3.gabc1234. pkgrel resets to 1, since a new upstream version restarts its packaging revisions. Also installs LICENSE into /usr/share/licenses — MIT is not in Arch's common licences, so a package under it has to carry the text. Arch is not part of the automated release (build-release.yml covers linux, windows and android), so v0.9.0 is unaffected; this applies to anyone building the package by hand.	2026-08-20 22:26:35 +02:00
dtourolle	20e2331560	chore(release): 0.9.0	2026-08-20 21:21:46 +02:00
dtourolle	bb140a8734	docs(release): write the v0.9.0 changelog and refresh artifact names ... release:notes is not usable for this batch: it maps changed files to their TRACES, and the logging sweep touched 63 files spanning most of the codebase, so it reports nearly every user requirement as changed — including ones explicitly not implemented. Written by hand instead. Also updates the checklist's artifact names for the rename and adds the rpm, which the checklist never listed because it was never published.	2026-08-20 21:07:13 +02:00
dtourolle	28b600304f	fix(scripts): check registry auth properly before pushing the builder image ... `docker info | grep Username` only reports a Docker Hub session, so for a private registry the guard never matched: every push dropped into an interactive docker login, which hangs a non-interactive run. Checks the credential store for the specific registry instead, and refuses with instructions rather than prompting when there is no TTY.	2026-08-20 21:06:23 +02:00
dtourolle	8fbf4d92cb	ci: match release bundles by extension, and ship the rpm ... Renaming the app to JellyTau renamed its bundles, and the release job globbed `bundle/deb/jellytau_*.deb`. The copy was wrapped in `if [ -f ... ]`, so the rename would have dropped the .deb from the release silently — a green build producing an incomplete release. Matching by extension removes the coupling between the product name and the pipeline, and an empty dist/linux now fails the job instead of passing quietly. That `if [ -f "dir/"*.ext ]` guard was also wrong on its own terms: with more than one match, test gets extra arguments and returns false. Found while verifying the rename: the rpm has been built by every release since deb+rpm became the bundle targets, and never copied, published or documented. It ships now. Also declares the package rename. Tauri kebab-cases productName into the Debian package name, so "JellyTau" produces `jelly-tau` — a different package from the `jellytau` earlier releases installed, which would have put a second copy alongside the old one. deb now declares Replaces/Conflicts/Provides and rpm Obsoletes/Provides, verified in the built control file. TRACES: | DR-214	2026-08-20 21:01:43 +02:00
dtourolle	d32ca13d00	chore: give the project its own identity instead of the scaffold's ... Cargo.toml still carried `description = "A Tauri App"` and `authors = ["you"]`, package.json's description was empty with no author or repository, and there was no LICENSE file at all despite package.json declaring MIT. The user-visible half matters more. productName was the scaffold's lowercase "jellytau", which is what the Android *release* build shows under its icon and what the deb/rpm/NSIS bundles carry as their display name. It went unnoticed because build.gradle.kts overrides the label to "JellyTau Debug" for the debug build type — the install a developer sees every day was the only correctly-cased one. mainBinaryName pins the executable filename to "jellytau" so build-windows-cross.sh and the Arch PKGBUILD, which both resolve it by name, need no change. strings.xml moves into the canonical android tree rather than being edited in gen/, since sync-android-sources.sh already copies res/values/*.xml — so the fix survives the next regeneration. Bundle metadata (publisher, copyright, category, descriptions, licence) was absent entirely, so the packages shipped with no maintainer or description. The hand-written PKGBUILD and .desktop had all of it; only the generated packaging was wrong. Adds .env.example: three scripts require signing vars from a gitignored .env and .gitignore already whitelists the example, but none existed. TRACES: | DR-214	2026-08-20 20:38:16 +02:00
dtourolle	2a3f08f8a4	build: hand containerised build artifacts back to the host user ... The compose services bind-mount the repo and build as root, so every artifact they leave in src-tauri/target belongs to root on the host. It accumulates: 11,124 such files had built up, enough that cargo clean and scripts/clean.sh failed with EACCES — and a plain cargo build died part-way through, because build scripts compile for the host and land in target/debug even when cross-compiling to Android. That is what blocked the device build in this batch. Restores ownership at the end of each containerised build, reading the intended owner from the checkout so no uid has to be plumbed through from the host. A no-op when not running as root, so the native build scripts call it unconditionally. Running the containers as the host uid is the tidier fix and stays open — it needs the cargo/bun cache volumes moved off /root first, which is why this is not a one-line user: directive. TRACES: | DR-213	2026-08-20 20:17:36 +02:00
dtourolle	68ca1d585d	chore: regenerate bindings and the traceability matrix ... bindings.ts picks up the library-exclusion commands and types from tauri-specta. The matrix regenerates because validation.ts and its test are gone — the doc link checker caught the stale references, which is the first time that gate has paid for itself on a generated artifact rather than a hand-written link. Also drops exclusions::is_excluded: a wrapper over is_excluded_by that only a test called, while the trait impls hoist the snapshot themselves. The test now calls the same path production does.	2026-08-20 20:14:15 +02:00
dtourolle	0815445aa7	feat(library): exclude chosen folders from music browsing ... Replaces a hardcoded filter that dropped anything named "Podcasts" from music results — one user's library layout compiled into the shipped product, keyed on an English literal, applied only at the six call sites someone had remembered. Exclusion is now a user setting stored in Rust and applied at the repository layer's convergence points, so scope is decided once and is the same on every screen. It matches on folder id rather than name: a title is not what an item is, which is why an album legitimately called "Podcasts" used to vanish. Deliberately not filtered: get_item (an id asked for by name was navigated to on purpose, and refusing it would break playback of anything inside a hidden folder), get_downloaded_items (hiding a download would leave the user unable to delete a file whose disk usage they can still see), and the offline cache (an exclusion is a view preference and must be reversible without a re-crawl). Also removes src/lib/utils/validation.ts — six exported validators with no caller outside their own test file, which made the module read as covered input validation while guarding nothing. TRACES: UR-076 | DR-209 | UT-203	2026-08-20 20:09:57 +02:00
dtourolle	048c99ebcc	fix(downloads): allow the deliberate join_absolute_paths lint in a test ... The assertion documents that PathBuf::join discards its base when handed an absolute path — which is why confinement has to happen after the join, not instead of it. clippy::join_absolute_paths flags that shape, correctly for production code, so the lint is allowed here rather than the test weakened. Worth recording: this lint would not have caught the original defect. The real join sites pass a variable, and it only fires on a literal.	2026-08-20 20:09:19 +02:00
dtourolle	34026d22b4	fix(logging): keep debug logging in a packaged debug build ... import.meta.env.DEV is true only under the vite dev server, but scripts/build-android.sh produces the debug APK with a plain `bun run build` — so the logger defaulted to warn there too and the debug package lost every frontend message from logcat. `bun run android:logs` is a documented workflow that depends on them. vite now defines __JT_DEBUG_BUILD__ from Tauri's TAURI_ENV_DEBUG, which the CLI sets while running beforeBuildCommand. The decision is split into a pure resolveDefaultLogLevel(isDevServer, isDebugBuild) because neither import.meta.env.DEV nor a vite define can be varied from inside a test. Also replaces the pinned requirement counts in extract-traces.test.ts with invariants. The pins guarded nothing the computeCoverage fixtures don't already cover, while forcing every branch that adds a requirement to edit the numbers — the comment above them had become a ledger of which branch contributed which row. TRACES: | DR-204 | UT-201	2026-08-20 20:06:51 +02:00
dtourolle	aeb29f916b	docs(requirements): add rows for the path-confinement and query-binding work	2026-08-20 20:03:43 +02:00
dtourolle	f83c7ed1f0	fix(downloads): confine download paths to the download root ... file_path and target_dir reached PathBuf::join unchecked from the frontend, and mark_download_completed stored a caller-supplied path that is later fed to remove_file. A correct sanitiser already existed — download_item_and_start used it — but download_item is itself a command taking file_path raw, so the guard was simply routed around. It now lives inside download_item, alongside a join-then-confine check modelled on media_server::resolve_path. Sanitising is per path component, not whole-string: the latter would silently turn downloads/x.mp3 into downloads_x.mp3 and relocate every existing download. TRACES: | DR-211 | UT-205	2026-08-20 20:03:04 +02:00
dtourolle	b313b61717	fix(repository): bind query parameters and encode URL values ... Three consistency fixes, each one applying a pattern the same file already used a few lines away: the offline get_items type filter now binds placeholders like search at offline.rs:1786 does, build_get_items_endpoint percent-encodes its values like the Genres block below it does, and player_set_volume clamps NaN and out-of-range input at the command boundary rather than relying on each backend to do it. TRACES: | DR-212 | UT-206	2026-08-20 20:02:57 +02:00
dtourolle	fb6bd5cae1	fix(thumbnails): confine cache writes to the cache directory ... item_id and image_type reached the cache filename unsanitised while tag was already being sanitised, and Path::join neither folds .. nor keeps the base when handed an absolute path. Applies the tag's existing rule to all three parts and adds a starts_with(cache_dir) check at the point of use, modelled on media_server::resolve_path. Not exploitable as shipped — server URLs must be HTTPS (auth/mod.rs) and Android blocks cleartext, so the id would have to come from a server the user chose to trust. This makes the write path consistent with how the rest of the codebase already handles caller-supplied paths. TRACES: | DR-210 | UT-204	2026-08-20 20:02:57 +02:00
dtourolle	da6b039b29	fix(downloads): confine download paths to the download root ... Both halves of the path a download writes to arrived from the frontend unchecked. `start_download` and the queue pump built their target as `PathBuf::from(target_dir).join(file_path)`, and `mark_download_completed` stored a frontend-supplied `file_path` on the row verbatim — the same column that is later read back into `std::fs::remove_file` when a download is deleted. A correct sanitiser already existed and `download_item_and_start` used it, but `download_item` is a command in its own right, so calling it directly routed the guard around. The guard moves inside. `confine_to_root` folds `..` away lexically and requires the result to sit inside the storage root, modelled on `media_server::resolve_path` — the check comes after the join because `Path::join` drops the base when the joined half is absolute, so an absolute `file_path` is obeyed rather than folded. `confine_queued_path` sanitises a queued path per component (so the already-safe name `download_item_and_start` passes in is not sanitised into a second, different one) and confines it. Applied in `download_item`, at both join sites, and to what `mark_download_completed` writes. Every path the app builds for itself is returned unchanged, including the absolute ones `download_series`/`download_season` produce from `${targetDir}/videos`, so no existing row or file on disk is orphaned. The pump fails an offending row rather than skipping it, because the pump re-queries and would otherwise not terminate. Not a live vulnerability: reaching these commands with hostile input needs script execution in a webview whose CSP is `script-src 'self'`. This is hardening and consistency. TRACES: DR-211 | UT-205	2026-08-20 20:01:52 +02:00
dtourolle	080cdbf383	fix(player): clamp volume at the command boundary ... player_set_volume passed `volume` through untouched. Each backend clamps to 0.0..=1.0 for itself, so local playback was already safe, but the remote branch reaches no backend: it converts with `(volume * 100.0) as i32`, which turns infinity into i32::MAX. NaN is handled explicitly since f32::clamp returns NaN for a NaN input and it then survives every comparison downstream. TRACES: DR-212 | UT-206	2026-08-20 20:00:35 +02:00
dtourolle	6b7ce512ed	fix(online): percent-encode query values and path ids ... build_get_items_endpoint pasted ParentId, IncludeItemTypes, SortBy and SortOrder straight into the query string while the Genres parameter twenty lines below and the SearchTerm parameter both percent-encode theirs. Encode them the same way, per list element so the commas Jellyfin splits on survive. The per-call ids interpolated into request paths (item, person and playlist ids) get the same treatment; a Jellyfin GUID is unchanged by encoding, so this is consistency, not a behaviour change. self.user_id is left alone throughout, as it is at the endpoint builders already. TRACES: UR-007 | DR-212 | UT-206	2026-08-20 19:59:25 +02:00
dtourolle	55b37ba2f4	ci: make clippy a hard gate ... The advisory step existed because the tree carried a warning backlog. Measured on 1.97.1 — the pinned toolchain CI actually uses — that backlog is three warnings, not the ~51 the comment claimed: two unnecessary_sort_by in smart_cache and one redundant into_iter in offline. Fixed, so clippy now runs with -D warnings and a warning means new breakage. Worth recording why this took a toolchain pin to do safely: the same tree measured 0 warnings on 1.92.0 and 3 on 1.97.1. Flipping the flag on a local measurement, without the pin, would have reddened CI on the next push. TRACES: | DR-206	2026-08-20 19:58:39 +02:00
dtourolle	d52470e0cd	fix(offline): bind item-type filter as query parameters ... get_items built its `AND i.item_type IN (…)` fragment by interpolating each requested type into the SQL string, while `search`, `get_favorites` and `prune_stale_catalog` in the same file bind the identical filter as `?` placeholders. Follow the existing pattern so the listing query is consistent with its neighbours. The type values bind between the six parent-matching ids and the favourites user id, matching where `{type_filter}` lands in the statement. TRACES: UR-065 | DR-212 | UT-206	2026-08-20 19:56:40 +02:00
dtourolle	e12f0065a6	fix(thumbnails): confine cache writes to the cache directory ... The thumbnail cache built its filename from `item_id`, `image_type` and `tag`, but only sanitised the tag. `Path::join` neither folds `..` nor keeps its base when handed an absolute path, so a malformed id could place a cache write outside the cache directory. Sanitise all three parts through one helper using the rule the tag already used (non-alphanumerics become `_`), so ids and types that were already safe keep producing exactly the same filename, and resolve the result against the cache dir with a lexical `..` fold plus a `starts_with` check, modelled on `media_server::resolve_path`. The database still stores the raw key and the resolved path, so the lookup in `get_cached_path` keeps matching what the caller asks for.	2026-08-20 19:56:23 +02:00
dtourolle	63d4df0cde	chore(tooling): keep lint and format out of the scratch worktrees ... .claude/worktrees holds full checkouts of this repo, generated .svelte-kit trees included, so 'eslint .' was linting every in-flight branch — 410 errors, none of them ours. Same root cause the doc-link checker hit.	2026-08-20 19:55:29 +02:00
dtourolle	6b90582e3e	chore(tooling): add lint/format gates, pin the toolchain, enforce commit checks ... Adds the frontend's first linter and formatter — the Rust half has had cargo fmt --check and clippy in CI for a while, while 274 TS/Svelte files had only svelte-check. ESLint runs clean; 159 findings are recorded as warnings rather than suppressed, so the backlog is visible without painting CI red. Also: `bun run test` no longer drops into watch mode (the "Before Committing" list told people to run a command that never returns), the traceability ratchet moves 82% -> 88%, a pre-commit hook enforces the fast half of that list instead of relying on memory, the dead webdriverio e2e suite and its five devDeps are removed, and the Rust toolchain is pinned to 1.97.1 so the developer machine and the CI builder image stop being five releases apart. TRACES: | DR-205, DR-206, DR-207	2026-08-20 19:53:13 +02:00
dtourolle	ea3c765561	chore: remove unused frontend validation module ... `src/lib/utils/validation.ts` exported six validators (validateItemId, validateImageType, validateMediaSourceId, validateUrlPathSegment, validateNumericParam, validateQueryParamValue). Nothing outside its own 213-line test suite ever called them, so the module read as covered, guarded input validation while guarding nothing — a green test run over code no input ever passes through. Deleting it does not weaken any check that was running; it removes the false assurance that one was. Note: the layer this validation belongs in per CLAUDE.md ("Validate all inputs in Rust command handlers") does not implement it either. That is a separate concern and is left untouched here.	2026-08-20 19:38:12 +02:00
dtourolle	ac3cd67164	feat(library): exclude chosen folders from music browsing ... Replaces `src/lib/utils/podcastFilter.ts` — a shipped personal workaround that dropped any item whose name, album, album artist or artist was literally "Podcasts" — with a real user setting applied in Rust. The old filter was wrong twice over: it hardcoded one user's folder layout keyed on an English literal, and it put a domain rule (what a query should return) in the presentation layer. It slipped past `check:boundary` only because it matched on names rather than on an item-type array. - `repository::exclusions` owns the rule and the process-wide id set, the same shape as `online::STREAMING_QUALITY` so it survives a repository being rebuilt on re-login. - `HybridRepository` applies it where the cache and server legs of every cache-first query converge (`parallel_race` / `race_with_refresh`), plus the bespoke `get_items` path and the server-only reads. Filtering before the "has content" check is what makes a cache page of nothing but hidden items fall through to the server. - Exclusion is by stable item id, never by name, and matches an item's own id or any container link it carries (parent, album, library, series, season, artist). - A direct `get_item` lookup and the Downloads surface are deliberately unfiltered: hiding those would break playback and file management of anything inside a hidden folder. - `LibrarySettings` persists to `app_settings` and is restored in the setup hook, alongside the streaming-quality cap. Default is an empty list — nobody inherits the old "Podcasts" behaviour. - New commands `library_get_settings`, `library_set_settings` and `library_get_exclusion_candidates`; the candidates read goes through `get_items_unfiltered` so an already-hidden folder still appears in the picker and the setting can be undone. - Settings page gains a "Hidden Folders" section that renders the backend's candidate list and sends back ticked ids; it decides nothing. TRACES: UR-076 | DR-209 | UT-203	2026-08-20 19:38:05 +02:00
dtourolle	f5bee069c0	fix(desktop): give the window a real title and a usable default size ... tauri.conf.json still carried the scaffold defaults: a lowercase "jellytau" title in an 800x600 window. The title is what the OS shows in the task switcher and window list, and 800x600 is too small for a media library grid with a mini player docked at the bottom. Now "JellyTau" at 1280x800, with minWidth/minHeight held at the old 800x600 so the layout still has a defined floor when a user drags the window small.	2026-08-20 19:36:21 +02:00
dtourolle	adcdadfcaf	ci: run the documentation link checker ... Wires scripts/check-doc-links.sh into build-and-test.yml next to the existing boundary tripwire, and exposes it as `bun run check:links`. The docs are the maintained source of truth for architecture and process and cross-reference each other heavily, so a rename that misses a link quietly turns a doc into a dead end. Pure shell — nothing is installed at job time. The script itself is landing separately; this job step is red until it does.	2026-08-20 19:36:10 +02:00
dtourolle	6406ca3fad	chore(tooling): add a pre-commit hook for the fast committing gates ... CLAUDE.md's five-command "Before Committing" list was enforced by memory alone. scripts/hooks/pre-commit now runs the half of it that finishes in seconds — `bun run check`, `bun run test`, check-frontend-boundary.sh, and `cargo fmt --all -- --check` only when staged files touch src-tauri/. `cargo clippy` and `cargo test` are left out on purpose. Minutes per commit is how a hook teaches people to type --no-verify; CI and `bun run test:all` are where the slow gates belong. Installed via `bun run hooks:install`, which sets core.hooksPath to the tracked scripts/hooks directory rather than copying into .git/hooks, so later changes to the hook reach everyone on their next pull. The hook runs every gate before reporting, so one commit tells you everything that is wrong rather than only the first thing. It exits 0 without running anything during a merge, rebase, or cherry-pick, and when nothing is staged; `git commit --no-verify` skips it as usual.	2026-08-20 19:36:02 +02:00
dtourolle	4af6ed0f98	build(rust): pin the toolchain to 1.97.1 for dev and CI ... The Rust toolchain was unpinned on both sides, and the two sides had drifted five releases apart: the CI builder image ships rustc 1.97.1, the development machine was on 1.92.0. Clippy's lint set and rustfmt's output both change between releases, so a green `cargo clippy` / `cargo fmt --check` locally said nothing about CI and vice versa — which is the reason the clippy gate could not be trusted enough to turn on. src-tauri/rust-toolchain.toml pins channel 1.97.1 with the rustfmt and clippy components. Deliberately no `targets` list: that would make rustup fetch the Android and Windows std libraries on every plain `cargo test`, including on machines that never cross-compile. The image already has them. Dockerfile.builder installs that exact version instead of "latest stable at rebuild time", and prints rustc/clippy versions so a mismatch is visible in the build log. The pin only becomes authoritative once the image is rebuilt and pushed (scripts/build-builder-image.sh). Until then CI still runs whatever rustc the current image has, and if that is not 1.97.1 rustup will download the pinned toolchain at job time — a toolchain install in CI, which CLAUDE.md forbids. Both files carry that warning next to the version. Note: the clippy step in .gitea/workflows/build-and-test.yml is left advisory here; tightening it wants a warning count measured on 1.97.1 first.	2026-08-20 19:35:51 +02:00
dtourolle	164157f98e	chore(ci): raise the traceability ratchet from 82% to 88% ... Actual coverage is 90% (`bun run traces:coverage`), so the gate had ~8 points of slack — a requirement could stop being traced and CI would not notice. Per the ratchet policy in the workflow, move it up to sit just under the real figure. MIN_COVERAGE_PERCENT in scripts/extract-traces.ts moves in lockstep: the workflow comment says to keep the two in sync and extract-traces.test.ts asserts it, so changing only the YAML turns the frontend suite red. (The stale "fails below 50%" comment in scripts/test-all.sh, wrong since the threshold moved to 82, was corrected in the preceding commit along with the rest of that file.)	2026-08-20 19:35:38 +02:00
dtourolle	95eb16d5ef	chore(tooling): add eslint + prettier, fix the test watch-mode default ... Three gaps in the frontend tooling, all in the package.json script surface. 1. No JS/TS linter or formatter existed at all for 274 TS/Svelte files. Adds an ESLint flat config (typescript-eslint + eslint-plugin-svelte, Svelte 5 + TS strict) and prettier + prettier-plugin-svelte, plus the `lint`, `lint:fix`, `format`, `format:check` scripts. The tree is error-clean (`npx eslint .` exits 0). Getting there needed seven real one-line fixes (braced switch cases that leaked `const` across arms, a useless regex escape, two `let`s that never change, a thrown Error that dropped its `cause`, and two `// eslint-disable-next-line` comments documenting the Svelte 5 bare-read-for-dependency idiom). Everything else that fires is set to `warn` with the reason written next to it in eslint.config.js — notably ~94 dead bindings and `any` at the IPC boundary. Those are real findings to drive to zero, not noise to delete. `no-console` is OFF for now: a parallel change is moving all ~468 console calls onto a logger facade, and turning the rule on today would collide with it. eslint.config.js says so, and says to flip it to `error` once that lands. `prettier --write` is deliberately NOT run here — it would rewrite ~200 files and swamp every other diff in flight. The gate is available; the sweep is a separate commit. Markdown and CI YAML are in .prettierignore because both are hand-laid-out (and docs/traceability.md is generated). 2. `bun run test` was bare `vitest`, i.e. watch mode — while CLAUDE.md's "Before Committing" list tells people to run it. It is now `vitest run`, with `test:watch` and `test:coverage` (also `--run`-ified) alongside. scripts/test-all.sh drops the now-redundant `--run`, and scripts/test-frontend.sh keeps `--watch`/`--ui`/`-w` working by routing them to a long-running vitest instead of the single-pass one. 3. The webdriverio e2e suite is deleted. It was last touched in January ("First working POC"), has never run since, and is not in CI — five devDependencies and two scripts of pure decoration. Removes e2e/, wdio.conf.ts, the two `test:e2e*` scripts, the @wdio/* + webdriverio devDeps, and the WebdriverIO block in .gitignore. The package.json diff also carries `hooks:install` and `check:links`, wired up by the following commits.	2026-08-20 19:35:17 +02:00
dtourolle	ae26d5356a	docs: fix remaining references to the moved build docs ... Updates the two referrers outside the docs tree that the move left behind, and excludes .claude/ from the link checker — the agent worktrees under it are full checkouts, so it was walking every in-flight branch and reporting their links as ours.	2026-08-20 19:34:44 +02:00
dtourolle	b025ed05f2	docs: repair the traceability matrix, link integrity and site nav ... Every file link in docs/traceability.md was broken — all 2,840. The generator emitted repo-root-relative hrefs from a file that lives in docs/, so the artefact the whole TRACES system exists to produce was unnavigable in the repo browser and on the published site alike. Fixed at the generator and covered by a regression test, since the markdown output had no test at all. Also: repairs the remaining broken relative links, adds scripts/check-doc-links.sh so this class of defect fails a build instead of rotting, publishes all 50 docs in the mdBook nav (was 21), moves the root-level build docs under docs/build/ for consistency, retires the stale v0.6.0 audit after confirming every still-open finding survives in the technical-debt table, and records the oversized-module debt. TRACES: | DR-208 | UT-202	2026-08-20 19:33:36 +02:00
dtourolle	2de91ae76c	docs: move the root-level build docs under docs/build/ ... build-release.md, build-desktop-packages.md and build-windows.md sat at the docs/ root while docker.md and build-builder-image.md were already in docs/build/, so "where do build docs live" had two answers. They now have one. Referrers updated: README.md, docs-site/SUMMARY.md, and the ../ links inside the moved files themselves, which each gained a level of depth — Dockerfile, Dockerfile.arch, packaging/arch/PKGBUILD, CHANGELOG.md, README.md, src-tauri/src/lib.rs and src/lib/services/webviewAudio.ts. Every one of those was caught by check-doc-links.sh rather than by reading, which is the point of having it. Two referrers are left for their owners: CLAUDE.md line 173 and the comment at scripts/build-windows-cross.sh line 11.	2026-08-20 19:32:04 +02:00
dtourolle	35157a6c59	refactor(logging): replace raw console calls with a leveled logger facade ... 484 ungated console.* calls across 63 frontend files shipped to end users — 248 console.log occurrences were verified present in the built bundle. The Rust half of the app has used the log crate with a LevelFilter and a RUST_LOG override since the beginning; the frontend had no equivalent. Adds src/lib/utils/logger.ts: four levels, scoped loggers replacing the hand-written "[Scope] " prefixes, debug in dev and warn in production, and a localStorage override so a user can turn verbose logging on in a shipped build to file a bug report. warn and error are never gated away. The sweep itself is mechanical — no control flow, error handling, or message semantics changed. TRACES: | DR-204 | UT-201	2026-08-20 19:31:57 +02:00
dtourolle	3b55810a0e	docs: publish every spec and build doc in the mdBook nav ... SUMMARY.md drives the mdBook build and mdBook renders only what SUMMARY references, so 31 of the 52 pages in docs/ were being written, reviewed and merged without ever appearing on the published site: 25 of the 26 specs (only video-background-audio was listed), plus build-desktop- packages, build-windows and defect-windows. The specs are grouped into themed sections — playback, library and browsing, downloads and offline, tooling and build — because a flat list of 28 is not navigable, with SPEC-TEMPLATE and SPEC-REVIEW-CHECKLIST kept together as the process docs someone reaches for before writing a spec.	2026-08-20 19:30:59 +02:00
dtourolle	bf72f9869a	build(scripts): add a documentation link integrity check (DR-208) ... Walks every tracked .md file, resolves each relative inline link against the directory the file lives in, and fails with the file:line and the unresolved target if it is not on disk. Skips http(s)/mailto, pure anchors, and links inside fenced code blocks (a template being shown to the reader is sample text, not a live link). This is the check that would have caught the 2,793 dead links in the generated traceability matrix at the commit that introduced them, and the handful of hand-written ones repaired alongside it. Nobody clicks 2,800 links, which is why the defect survived for months. Two documented exceptions rather than silent ones: docs-site/SUMMARY.md is copied into docs/ by publish-docs before rendering, so its links are resolved from docs/ — which is what makes it catch a nav entry pointing at a page that does not exist; and docs/README.md and docs/api-redirect.md are generated by that same job and so are absent from the repo by design. The header states what it deliberately cannot see, in the house style of check-frontend-boundary.sh: it validates paths, not anchors. Resolving a fragment needs a renderer's heading-slug rules, which differ between Gitea, GitHub and mdBook, so a link to a renamed heading still passes. The package.json script and CI wiring are added separately.	2026-08-20 19:30:59 +02:00
dtourolle	4567c63797	docs: raise the documented traceability gate to 88% ... The spec review checklist still asked for >= 50%, the figure the gate sat at before it was found to be unreachable; traceability-ci.md carried 82% throughout. Both now read 88%, matching the ratchet, and the checklist points at `bun run traces:coverage` rather than inviting anyone to trust a number written in a document. Also refreshes the two stale coverage snapshots in traceability-ci.md (~86% from July 2026, and targets of 70% and 90% that the current 90% already passes) and records the 50 -> 82 -> 88 ratchet history.	2026-08-20 19:30:48 +02:00
dtourolle	46a5219f8e	docs: repair broken relative links ... - traces-quick-ref.md: the four "where to find requirements" links pointed at README.md, but those anchors (#1-user-requirements and friends) live in requirements.md; the "See Also" links were written as if the file sat at the repo root (docs/traceability.md from inside docs/); and the extraction-script link needed ../ to reach scripts/README.md. - release-checklist.md: the release-notes template linked ../../CHANGELOG.md (one level too deep) and ../../issues + ../../discussions, which are GitHub relative-URL idioms. The canonical remote is Gitea, whose release bodies render the template outside any repo path, so these are now absolute gitea.tourolle.paris URLs. Gitea has no discussions, so that link is dropped rather than pointed somewhere it does not exist. - specs/favorites-browsing.md: linked the deleted src/lib/utils/tauriIntegration.test.ts.	2026-08-20 19:30:48 +02:00
dtourolle	1518d92ef4	fix(traces): make generated matrix links resolve from docs/ ... docs/traceability.md emitted each trace's file link with the repo-root-relative path as the href, but the file is written to docs/ — so every one of the 2,793 links resolved to docs/src-tauri/... or docs/src/... and 404'd, in the Gitea repo browser and on the published mdBook site alike. The matrix is the artefact the whole TRACES system exists to produce, and it was unnavigable. The href now carries a ../ prefix; the visible link text stays repo-root-relative, since that is the path a developer greps for. This survived because the markdown generator had no test at all — the existing suite covers counting, coverage and dangling IDs only. UT-202 now generates a link for a file that really exists, resolves the href against docs/, and asserts the target is on disk; it fails against the old output. Watched red before the fix, per the red-green rule. The live-requirements counts move with the rows added in the previous commit: UR 75 -> 76, DR 194 -> 200, total 337 -> 344.	2026-08-20 19:30:37 +02:00
dtourolle	662cb3cd85	docs(requirements): add new IDs, retire the v0.6.0 audit, record module size ... Adds the requirement rows other work in flight needs so `traces:validate` stays green: DR-204 (frontend logging facade), DR-205 (ESLint + Prettier gate), DR-206 (pinned Rust toolchain), DR-207 (pre-commit hook), DR-208 (documentation link integrity), DR-209 (server-side library folder exclusion) and UR-076, plus §4 test rows UT-201, UT-202 and UT-203. Deletes docs/codebase-audit.md. It was a 2026-08-16 snapshot of v0.6.0 at commit be907b49 with no status markers, three releases stale, describing code that had since changed — a document that half-describes the codebase is worse than none. Everything in it still genuinely open already lived in §5's table; the §5 preamble now records what was dropped as closed and why, so nothing is silently re-raised or silently lost. Also rewrites §5 row 11 with today's figures and the actual cost: the six oversized modules are the same ones CLAUDE.md's Gotchas section keeps having to warn about, which is the price being paid. Recorded, not scheduled. Fixes a dead link to the removed src/lib/services/playbackControl.ts, which now points at src/lib/utils/playbackUnits.ts.	2026-08-20 19:30:30 +02:00