155 Commits

Include renames

Author	SHA1	Message	Date
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	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	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	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	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	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	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	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	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	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	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	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	d54d8cc7c4	refactor(logging): route frontend console calls through the logger ... TRACES: | DR-204 484 ungated `console.*` calls across 63 non-test frontend files shipped to end users with no way to turn them off. Mechanical substitution, no control flow, error handling or message semantics changed: console.log / console.debug -> log.debug console.info -> log.info console.warn -> log.warn console.error -> log.error Hand-written `"[Scope] …"` prefixes are dropped where the logger's scope now carries them; scope names that already existed are preserved verbatim (`[Auth]`, `[VideoPlayer]`, `[PiP]`, …) and inferred from the filename where a file had none. `src/routes/player/[id]/+page.svelte` keeps its `NextEpisode` and `AutoPlay` sub-scopes as separate loggers rather than flattening them into the page scope. `grep -rn 'console\.' src/` now matches nothing outside the tests and the facade itself.	2026-08-20 19:29:59 +02:00
dtourolle	4c82a0a025	feat(logging): add leveled logger facade ... TRACES: | DR-204 | UT-201 The Rust half of the app logs through the `log` crate behind `env_logger`, with `LevelFilter::Info` by default and `RUST_LOG` to turn the volume up without a rebuild. The frontend had no equivalent at all: every `console.log` written during development shipped to end users. `createLogger(scope)` gives the frontend the same shape: - four levels (debug/info/warn/error), gated by severity; - verbose in dev, `warn` in production — warn and error are never gated away, because a silent failure in a networked media client is worse to support than a noisy console; - `localStorage["jellytau:logLevel"]`, read once at init, as the `RUST_LOG` equivalent so a user can gather verbose logs for a bug report without a rebuild. Guarded for SSR and for webviews where storage access throws; - the scope replaces the hand-written `"[Scope] …"` prefixes; - a thin pass-through: arguments reach `console.*` untouched and by reference, and `console` is resolved at call time so devtools overrides and test spies still see everything.	2026-08-20 19:29:48 +02:00
dtourolle	4e451bb534	chore(bindings): regenerate specta output for the new TRACES doc comments ... tauri-specta propagates Rust doc comments into bindings.ts as JSDoc, so adding TRACES comments to command functions changes generated output. Regeneration happens at build time, so this was left dirty by the branch that added them. Doc-comment-only: no signature or exported-symbol changes. Also records the audit corrections made during device verification (B1 mechanism, B7 re-framing, B8, D3 magnitude).	2026-08-16 23:15:58 +02:00
dtourolle	c9f33ae6a4	merge: restrictive CSP and narrowed asset scope (C1, C2) ... Set a CSP with script-src 'self' (Tauri nonces the one inline bootstrap script), object-src/frame-src 'none', and necessarily-permissive img/media/connect for the user-supplied Jellyfin origin. Narrow assetProtocol $APPDATA/** -> thumbnails/**, which is convertFileSrc's only remaining caller. Conflict resolution: scripts/extract-traces.test.ts pinned counts summed rather than side-picked — DR-189 and DR-198 were added independently on two branches, so DR 187 -> 189 and total 330 -> 332. docs/traceability.md regenerated.	2026-08-16 23:01:50 +02:00
dtourolle	4996727ca9	merge: enforce CI gates the contributor rules already required (D1, A3, A4, D2) ... Add cargo fmt --check (strict) and cargo clippy (advisory) to CI, ratchet the traceability threshold 50 -> 82, add a dangling-ID gate, and fix the offlineCatalog flake (cold dynamic import, not a timer).	2026-08-16 23:00:58 +02:00
dtourolle	ebf9a99b80	docs(traces): tag the twelve "Done but untraced" requirements, and stop the matrix over-reporting ... Twelve requirements were marked Done in docs/requirements.md with zero TRACES anywhere in the tree. The features work — the tags were simply never written — so the matrix over-reported on exactly the requirements a reviewer would most want to verify. Each is now tagged at the code that actually implements it: - JA-006 / JA-009 / JA-013 / JA-014 / JA-015 / JA-018 and IR-022 / IR-024 at their Jellyfin call sites in repository/online.rs (search, get_item's MediaStreams/People fields, Items/Resume, Shows/NextUp, FavoriteItems DELETE, get_person/get_items_by_person), plus the commands that expose them. - UR-006 / IR-006 across the lockscreen spine: JellyTauPlaybackService (the MediaSessionCompat owner), the nativeOnMediaCommand JNI intake, and LockscreenMetadata / update_lockscreen_metadata. - IR-008 at both audio-focus mechanisms — ExoPlayer-managed for audio, the manual AudioFocusRequest listener for video — and at the media-type string that chooses between them. - UR-037 (with DR-042, also untraced) on the video-library poster grid: LibraryGrid, MediaCard, and the tv/movies routes. Resolve contradictory statuses across layers, evidence first: - IR-018/IR-019 were Planned under Done URs because they were scoped to libmpv. MpvBackend is the audio-only backend and overrides neither set_subtitle_track nor set_audio_track — the trait's not_implemented() default still stands — so UR-020/UR-021 are met by ExoPlayer and by the HTML5 <video> path instead. Both IRs are re-scoped to those backends and marked Done; IT-008/IT-009 and the stale @req-planned markers in backend.rs follow. - IR-005 (MPRIS) stays Planned: there is no MPRIS/D-Bus code or dependency in the project and update_lockscreen_metadata is a no-op off Android. UR-006 is corrected to Done (Android) rather than the IR being marked Done. - A note under the IR table records where a UR is met by a different mechanism than its IR anticipated. Define the two dangling IDs the source already referenced: DR-189 (the control bar never auto-hid on a touchscreen, because its timer was armed only from onmousemove) and UT-188 (its rule test). The live-denominator assertion in extract-traces.test.ts moves 187/330 to 188/331 accordingly. Traced requirements 444 to 459; IR coverage 19/32 to 25/32.	2026-08-16 22:58:55 +02:00
dtourolle	38dd1129e5	feat(security): set a restrictive CSP and scope the asset protocol to thumbnails ... `app.security.csp` was `null`, so the webview ran with no Content-Security-Policy at all: any script that reached the web layer would have inherited the whole IPC surface. There is no known injection path today (one app-owned `{@html}`, no `innerHTML`/`eval`), so this is defence in depth rather than a fix for an open hole. `script-src 'self'` is the restrictive half — Tauri nonces SvelteKit's inline bootstrap script at build time, so no `'unsafe-inline'` is needed — together with `object-src`/`frame-src 'none'` and `base-uri 'self'`. `img-src`/`media-src`/ `connect-src` cannot be restrictive: the Jellyfin origin is typed in by the user at run time and is routinely plain http on a LAN, so they allow `http:`/`https:`. That is a wide grant for data, but it still bars `file:`/`filesystem:` and does not touch script execution. A run-time policy naming the server exactly was rejected: Tauri derives the header from immutable config when it serves the HTML, so it would mean rebuilding config and reloading the webview on every server change. `style-src` keeps `'unsafe-inline'` because Svelte compiles `style="…"` attributes into markup; `worker-src`/`media-src` keep `blob:` for hls.js's demuxer worker and its MSE object URL; `ipc:`/`http://ipc.localhost` keeps `invoke` working. `devCsp` mirrors it with the eval/inline/websocket allowances Vite's dev server needs. The asset-protocol scope narrows from `$APPDATA/**` — the storage root holding the SQLite database and the encrypted-token fallback file — to `$APPDATA/thumbnails/**`. Since DR-137 moved downloaded media to the loopback media server, `imageCache` is the only `convertFileSrc` caller left. Needs manual verification on both platforms: thumbnails, online HLS video and offline downloaded video cannot be exercised headlessly.	2026-08-16 22:58:53 +02:00
dtourolle	b9dab56379	ci: enforce the checks the contributor rules already required ... Four gates that were documented but unenforced, plus the flaky test that made a full-suite run untrustworthy. Rust lint/format: CLAUDE.md has required `cargo fmt` and `cargo clippy` before every commit for as long as the rule existed, yet neither ran anywhere in CI — the requirement rested on memory alone. Both now run in build-and-test.yml and build-release.yml. rustfmt and clippy are already baked into the builder image, so nothing is installed at job time. `cargo fmt --all -- --check` is strict immediately (the tree is clean). Clippy is advisory for now: ~51 pre-existing warnings mean `-D warnings` would fail on unrelated work, so the step carries a TODO to flip the flag once the backlog clears. A compile error still fails it, so it is not a no-op. Traceability threshold: MIN_THRESHOLD sat at 50 while real coverage was 86%, so nearly half the matrix could rot before the gate objected. Ratcheted to 82 with the policy written down — it only ever goes up, and is never lowered to make a red build pass. The same figure lives in MIN_COVERAGE_PERCENT so `traces:coverage` gates locally on the same bar, and a test fails if the two drift. Dangling IDs: a TRACES comment could name any well-formed ID and the extractor accepted it silently, so typos and renames that missed a call site passed unnoticed. `bun run traces:validate` cross-checks every traced ID against the table rows in requirements.md and fails with the referencing files listed. It spans UT/IT as well, which the coverage orphan list ignores by design. This currently reports DR-189 and UT-188, which are being defined separately. Flaky offlineCatalog test: the first dynamic import of the service paid ~1s to transform its dependency graph, charged to a test body against vitest's 5s default. Alone it passed; under suite-wide contention it timed out. The import is now warmed at collection time, so no test is timing the compiler — the timeout is deliberately unchanged. The store shim also drops subscribers from module instances discarded by resetModules, which previously leaked across tests.	2026-08-16 22:51:44 +02:00
dtourolle	be907b4945	fix(home): stop Next Up repeating Continue Watching ... Jellyfin's /Shows/NextUp defaults EnableResumable=true, which returns a partially-watched episode as its own series' next up — precisely the episode /Items/Resume already returns. Home's "Next Episode" row and the TV landing's Next Up row therefore duplicated Continue Watching card for card. build_next_up_endpoint now sends EnableResumable=false, and because servers predating that parameter ignore it, filterInProgressNextUpItems also drops any next-up entry whose id appears in the resume list. It is the mirror of DR-089 and sits beside it: presentation-layer de-duplication over two lists the frontend already holds. The resume filter still reads its frontier from the unfiltered Next Up list, so pruning in-progress entries cannot resurrect a stale resume card. The code changes were swept into 5e8efa25 by a concurrent `git add -A`; this carries the remainder — DR-197 / JA-036 / UT-190..192, the renumbering off the DR-196 collision that commit created, the regenerated matrix, and the requirement-count guard. TRACES: UR-059 | DR-197, JA-036 | UT-190, UT-191, UT-192	2026-08-16 22:18:06 +02:00
dtourolle	3b9a8ad695	test(player): pin the native-video default and the opt-out that must survive it ... The default has moved four times, so the risk is not which way it points but that a flip silently overrides people who chose. The previous reader was getItem(KEY) === "true", which conflates "never chose" with "chose off" — under it, flipping the default re-enables the native path for everyone who had deliberately turned it off. The three cases are pinned separately so that conflation cannot come back.	2026-08-16 22:16:39 +02:00
dtourolle	ab95f5013d	feat(player): make native Android video the default ... The two defects that were holding the flip back are fixed and verified on a device, which is the standard this default has been held to since DR-161 shipped a verified sub-path over an unverified one: - returning from background audio restarts the renderer that is actually on screen, instead of only ever reloading the <video> element (DR-196) - the letterbox bars are painted, instead of retaining whatever was last in the framebuffer (DR-194) Evidence: handoff to audio-only at 69:54 returning to video playing at 70:18, and clean bars across playback, the control bar and a rotation round-trip. An explicit stored choice still wins in both directions, so anyone who turned the flag off keeps it off — hence the null check on the stored value rather than a bare === "true", which would silently re-enable it for people who opted out. The Settings copy no longer tells users to leave it off; it now describes the toggle as the fallback to the built-in web player. The flag keeps its "experimental" name because it remains a suppressor of Rust's backend choice, never a promoter: turning it on cannot produce a native backend where Rust says HTML5.	2026-08-16 22:14:43 +02:00
dtourolle	5e8efa252e	fix(player): restart the native renderer when returning from background audio ... With native video on, coming back from background audio left a black screen: a play overlay pinned at 0:00, a seek bar at zero, and a play button that did nothing. Nothing crashed — the process stayed up and the frontend kept logging — the transition was simply dropped. The two render paths resume by different means, and exitBackgroundAudioHandoff only ever performed one of them. The webview <video> reloads off its stream URL: an $effect watches it, reinitialises HLS or sets element.src, and canplay drives the seek and play. ExoPlayer owns no element and nothing watches the URL on its behalf — native playback is only ever started by an explicit player_play_item plus adapter load, which the component issues once, from onMount. So reassigning the URL restarted precisely nothing, and since player_exit_background_audio had already stopped the handoff's audio player, the backend came back holding no item at all. That is why the play button was inert: there was nothing loaded to play. The return now re-issues that pair on the native path, in the same order as the initial load, carrying the position the audio reached. Subtitle configurations are reused from the ones resolved at mount — ExoPlayer sideloads them as MediaItem.SubtitleConfigurations and cannot accept one after prepare(). Which path to take is decided by planHandoffReturn, a pure helper in backgroundAudioHandoff.ts, so the branch is unit-testable without mounting the player. It also folds in shouldResumeOnForeground, so a pause taken on the lockscreen during the handoff still wins over the snapshot captured on the way out. Verified on device (HONOR ROD2-W09, Android 16): handoff to audio-only at 69:54, return restored native video playing at 70:18. Previously the same sequence left the player idle and black. The requirements count pin in extract-traces.test.ts moves with the new DR-196.	2026-08-16 22:10:14 +02:00
dtourolle	8e98e1c37a	test(player): answer the commands the tap-surface tests actually render ... VideoPlayer.tapSurface.test.ts deliberately does not mock $lib/api/bindings — it renders the real component against the real bindings, which bottom out in the globally mocked `invoke`. That mock resolves `undefined` for every command, so any command whose result is *rendered* blows up: the quality picker assigns the result straight to state and the template then reads `streamingQualities.length`, which throws on undefined. It threw asynchronously, outside any test, so the suite reported 4 unhandled errors while every test still passed — the state vitest warns "might cause false positive tests". Answering the two rendered commands removes them. Authored in the main checkout; brought in here and verified: 83 files, 1009 tests, and the unhandled-error count drops from 4 to 0.	2026-08-16 21:20:55 +02:00
dtourolle	c142568230	fix(player): make transport reach the player that is actually rendering ... Play/pause did nothing on the Android native video path — from the on-screen tap, from the control bar, and from a direct player_toggle invocation — while seek and skip kept working. That asymmetry was the whole clue: seek decides in player_seek_video, transport decides in toggle_playback. DR-195 is the cause. `html5_playing` is Rust's record of "a webview <video> is active and in this state", and toggle_playback/play/pause all route transport to that element whenever it is set. The player route mirrored element state into it UNCONDITIONALLY — from handleReportStart and, fatally, from handleReportProgress, which VideoPlayer calls on a 10-second interval. So on the native path the frontend re-declared every ten seconds that an element was playing when none existed, and every transport intent was emitted into the void. It also explains the flashing: the control bar and the JRay overlay both key off isPlaying, which was being contradicted on every tick. The mirror now lives in mirrorElementStateToRust() in VideoPlayer, gated on useHtml5Element — the only place that knows whether an element renders at all. The route cannot tell the paths apart, which is exactly how it came to lie. DR-193 hands transport authority back to the native backend when an item loads into it. Necessary but insufficient alone: the progress interval put the flag straight back, which is why the first device test after it still failed. DR-192 presents native video through a TextureView instead of a SurfaceView. A SurfaceView renders on its own layer outside the app window and punches a transparent region through it, and everything drawn above that hole — here, the entire Svelte UI — depends on that composition path. The overlay dropped its incremental damage: the DOM advanced (slider 476 -> 479 across three seconds) behind a screen showing neither, so the progress bar froze, controls would not fade and rotation lost the transport UI, while structural DOM changes got through, which is why the play overlay always appeared to work. It supersedes DR-191, which forced redraws in a loop and treated the symptom. DR-194 hides the video view across a resize and reveals it two frames later. A TextureView retains its last frame, so between a rotation and the re-fit landing that frame is stretched across the old rect and the previous frame flashes in what should be the letterbox bars. Verified on device (Honor ROD2-W09, Android 16) by driving ADB and reading the live DOM over the devtools socket: surface tap pauses (position frozen across 12 seconds, overlay raised, transport flipped) and resumes; the control bar does both. UT-189 drives the real 10-second interval under fake timers — an earlier version asserted on a freshly mounted player, passed with the guard deleted, and guarded nothing. Still open, and deliberately not claimed: DR-192's effect on the overlay repaint is unverified on device, DR-194's letterbox reset is untested, and the native default (DR-188) stays off pending DR-190, the background-audio return.	2026-08-16 18:03:22 +02:00
dtourolle	95129d04a3	fix(player): make Android native video actually visible, and usable ... DR-172 reverted native video to opt-in after it shipped as audio with no picture, naming the compositing as the suspect. The compositing was fine. Five separate defects sat between ExoPlayer and the screen, each able to produce that exact symptom on its own, and each invisible to the others. DR-185 — the app shell painted over the surface. app.css clears the page's opaque layers through three selectors, one of which targets `[data-app-shell]`, an attribute NO component has ever set, in any commit. The shell paints --color-background across the whole viewport and VideoPlayer stacks above it, so the WebView composited opaque no matter what else was cleared. Invisible three ways over: the CSS is valid, the selector is plausible, and a rule matching nothing looks exactly like a rule matching something already transparent. DR-182 — nothing could lift the poster card. Every markMediaReady() call site is an HTML5 <video> event, and the native branch renders no element, so the black title card covered the surface for the entire session. The first fix hooked `player://position-update` / `player://state-changed`; those channels are never emitted by the backend, so it passed a test that fired them by hand and did nothing on a device. Driven from the player store now, as the seek bar already was. DR-183 — the JS bridges raced the page load. Installed 500ms after onCreate by walking the view tree, while WebView binds injected objects at page-load time, and the identity guard then declined to re-inject forever. setTransparent(true) could never arrive. Installed from WryActivity.onWebViewCreate instead, which wry calls immediately before the first loadUrl. DR-184 — the SurfaceView was never detached. detachVideoSurface had no callers anywhere, mirroring the DR-151 defect: every native video left its surface parented to the content view and the next one stacked another beneath it. DR-191 — the overlay stopped repainting. Incremental damage (the clock's text, the control bar's opacity) never reached the screen while structural changes did, so the progress bar froze, the controls would not fade, and the play overlay appeared to work because it is added and removed from the DOM. Driven from the Activity via postInvalidateOnAnimation while compositing is on. Two UI defects only this path could reveal came with them: isPlaying froze at its initial value, leaving the play overlay dimming and covering the video (DR-186), and the control bar's auto-hide was armed solely by mousemove, which a touchscreen never fires (DR-189). Immersive mode now applies on entering the player rather than only via the fullscreen button (DR-187). Verified on a device (Honor ROD2-W09, Android 16): logcat carries `WebView transparent = true` and `Marking media ready` with video on screen — the pair DR-172 went looking for and could not find — and skip, seek, rotation and subtitle rendering were exercised by hand. The default stays OFF (DR-188). Turning it on surfaced a further unverified sub-path: returning from background audio is HTML5-only, so playback stays dead (DR-190, proposed). Shipping it would have repeated DR-161 exactly — a verified sub-path made default over an unverified one.	2026-08-16 15:28:10 +02:00
dtourolle	c0c6c5023e	fix(player): resume a transcoded video by seeking, not by asking for a stream that starts mid-item ... A resumed transcode played nothing at all: every segment came back 400, hls.js exhausted its retries and gave up, while the same episode from the beginning was fine. Jellyfin builds each segment URI by echoing the master playlist's query string into it, and its segment handler opens by rejecting any request carrying StartTimeTicks > 0 (ArgumentException → 400). So one resume position on the playlist is copied onto every hls1/main/N.ts and 400s all of them — the `> 0` being exactly why starting from the beginning survived. HLS does not need the parameter: a playlist spans the whole item and asking for segment N *is* the seek. It is removed from the URL builder entirely rather than conditionalised — the builder cannot know whether its response will be segmented — and the position becomes a seek issued once the player has loaded. The progressive /Audio/universal builder behind the background-audio handoff has no segments and keeps its StartTimeTicks, which is why audio-only handoffs resumed correctly and video ones did not. Completing that across the boundary, since the URL no longer starts where the caller asked: - reloadSource(url, position) now means "reload and resume AT this absolute position": it seeks the element once the source is playable and clears the transcode offset to zero. It previously set the offset to the position and seeked nothing, which was correct only while the URL itself began there — left in place it would have shown 20:00 on the scrubber while the opening titles played, with no seek ever happening. - The transcoded resume path in the player page collapses into the same "seek after load" branch direct streams already used. - VideoPlayer's background-audio return does the same: no base, seek to the absolute position. - The stale test asserting StartTimeTicks is present is rewritten to keep its other half (an HLS master playlist, never a progressive stream.mp4, carrying the chosen source and audio track). TRACES: UR-004, UR-005, UR-019, UR-021, UR-074 | DR-181 | UT-182, UT-183	2026-08-16 11:08:42 +02:00
dtourolle	de1c13e72f	fix(player,reporting): report real positions, and count an audio-only episode as watched ... Returning to the foreground before the background-audio stream had started playing handed the frontend 0.0s, so the video reloaded at StartTimeTicks=0 — the episode restarted from the beginning — and the stop report that followed wrote that zero to Jellyfin as the resume point. Caught on device: locked at 18.4s, unlocked 3.5s later with ExoPlayer still IDLE. The base that turns a handoff's relative timeline into the episode's is applied once at the native tick boundary (DR-159), so before the first tick nothing has applied it. The same blind spot covers webview-rendered media, where nothing is loaded into the native backend at all and its position is a permanent 0 — which is why 14 of 14 stop reports in a 35-minute trace were zeroes, one landing 40s after the frontend had correctly reported 15:22 for the same episode. - absolute_position(): the maximum of the backend's reading, the last position webview media reported, and the handoff base. Exact rather than heuristic — at most one term is ever meaningful, and the base is a floor the stream cannot physically be behind. duration() gains the same fallback. - Withhold zero-position stop reports. A zero is never information, and Jellyfin stores the reported position as the resume point, so sending one only ever destroys a real one. - Report progress from the controller's own position ticks, through the 30s throttler it already shared with the native audio path. /Sessions/Playing/Progress was previously requested zero times in 35 minutes. - Report a finished audio-only episode stopped at its runtime before advancing, so Jellyfin's 90% rule marks it played. Nothing else can: the webview is suspended and its <video> was torn down at the handoff. - Split the handoff by source — a downloaded file takes no base and a real seek, a stream keeps its StartTimeTicks base and no seek — and stop routing a downloaded handoff's absolute seek through the stream rebuild, which refuses a non-remote source outright. Reports go through a PlaybackReportSink, which also collapses three copies of spawn-a-task-and-hope into one and is what let each of these be written as a failing test first. TRACES: UR-005, UR-025, UR-040, UR-071 | DR-178, DR-179, DR-180 | UT-176, UT-177, UT-178, UT-179, UT-180, UT-181	2026-08-16 10:23:00 +02:00
dtourolle	5096c01960	fix(player): restore the subtitle sidecar work dropped by the previous commit ... The previous commit was assembled from a tree read before 13264e22 landed, so committing it reverted that commit's changes: the image-based subtitle filtering in device_profile/types, subtitleTracks and its tests, the regenerated bindings, and the VideoPlayer menu wiring. Nothing was lost — the working tree held both changes throughout. This restores those files to the merged state, leaving both the subtitle fix and the play-session fix in place. TRACES: UR-020, UR-004 | DR-176 | UT-168	2026-08-16 10:20:22 +02:00
dtourolle	2d67b0e4f5	fix(player): give every transcode its own play session, and stop the one it replaces ... Switching bitrate mid-film stalled playback. The server served the new playlist and then rejected its segments: 400 on hls1/main/0.ts, six times over 25 seconds, never recovering, while the UI logged "Streaming quality changed" as if nothing were wrong. Jellyfin keys a transcode job by device and play session. Every stream URL this app built carried the same hardcoded DeviceId and no PlaySessionId at all, so the second stream for an item was indistinguishable from the first and nothing ever stopped the old ffmpeg. Re-opening a stream is not rare — a quality switch, a transcoded seek and an audio-track switch all do it. Replayed against the server, a second stream opened for a live job's item alternates per attempt between serving bytes and 400ing, which is why it read as flaky rather than broken. begin_video_play_session mints a session id per open and reports the one it supersedes; the URL builder stops that job (DELETE /Videos/ActiveEncodings, un-retried — a slow stop must not delay playback) before returning. Putting it in the builder rather than in each caller covers every re-open path by construction. adopt_video_play_session takes ownership of the job the server starts itself when PlaybackInfo answers with a TranscodingUrl: without it the first switch on a stream has nothing to stop and collides with what is playing. Two client faults made the same incident worse and go with it: - The fatal-HLS-error handler added the transcode seek offset to a position that already included it. Past roughly the halfway mark of a film the doubled value cleared the "near end" threshold, so any transient network error was reported as end-of-stream and autoplay skipped to the next item — precisely when a quality switch had just made the offset large. The decision now lives in hlsRecovery.ts, against the absolute position. - The HTML5 reload primitive resolved on its own canplay timeout, so a reload the server never served reported success. The picker showed a quality that was not playing and the caller had nothing to revert. TRACES: UR-074, UR-004 | DR-177 | UT-173, UT-174, UT-175	2026-08-16 09:47:27 +02:00
dtourolle	13264e225b	fix(player): never let the server burn a subtitle in, and never offer one we cannot draw ... Reported as "subtitles are shown even when off", and no toggle in the app cleared them — because they were not the app's subtitles at all. The server was painting them into the video. `PlaybackInfo` omitted `SubtitleStreamIndex`, which does not mean "none": the server then honours the source's own default/forced flag. On the reported episode that default is a PGS track — a bitmap, which cannot go out as a sidecar — so the server fell back to `SubtitleMethod=Encode` and composited it onto every frame. Confirmed against the live server, which answered the same PlaybackInfo request two ways: with the index omitted it returned `SubtitleStreamIndex=2` + `SubtitleMethod=Encode` and a `SubtitleCodecNotSupported` transcode reason, and its ffmpeg command carried `[0:2]…[sub];[main][sub]overlay_qsv=…`; with `-1` it selected no subtitle stream at all. The cost landed on the video, not the subtitle: burn-in rules out remuxing, so a stream that only needed its audio transcoded was re-encoded frame by frame. Three parts: - The negotiation asks for `SubtitleStreamIndex=-1` and advertises every text format we can render (srt/subrip/ass/ssa/vtt) as `External`. - The stream URL says the same thing, because the negotiation is not what opens most streams: a quality switch, a transcoded seek and an audio-track switch each rebuild the URL on their own, and an omitted index there lets the server pick the default track back up out of whatever session state it still holds. - The picker offers only subtitles the app can actually draw. Each subtitle stream now crosses the boundary carrying `supports_external_delivery`, decided in Rust where the codec vocabulary belongs, and `None` for anything that is not a subtitle so a `false` cannot be misread as a verdict. `subtitleStreamsOf()` drops the rejected ones — and since that one function feeds the menu, the `<track>` children and the native play request alike, a bitmap track disappears from all three without its URL ever being fetched. Only an explicit "no" hides a track; a stream carrying no verdict behaves exactly as before. Nothing is lost by refusing burn-in: the app already fetches the text tracks and draws them itself (UR-020), so the server's composited copy was always redundant. Image-based tracks are consequently not offered, which is honest rather than a regression — the renderer cannot composite a bitmap, and the old behaviour paid for them by making the whole stream unwatchable. Tests were written first and observed failing: the Rust one would not compile against a field that did not exist, and the frontend one resolved a URL for the PGS track it was supposed to drop. Carries with it the in-flight per-stream `PlaySessionId` work in online.rs, whose hunks sit inside the same request builder and could not be separated from these. TRACES: UR-020, UR-004 | DR-176 | UT-168	2026-08-16 09:47:09 +02:00
dtourolle	1a9805f0f3	fix(downloads): queue the whole album, and make every queued track findable offline ... An album download put a handful of its tracks on the device while the button reported the album as downloaded. Two independent gaps, one shared cause. - `download_album` read its track list from `items WHERE album_id = ?` — the local catalog cache. Jellyfin does not return `AlbumId` on every listing endpoint, so tracks cached from one of those sit in `items` with a NULL `album_id` and are invisible to that query. On the reported database three whole albums (18, 12 and 9 tracks) had it NULL on every track; a partially linked album queued only the linked subset. - The frontend then resolved one stream URL per track from its own list and paired it with the returned row ids by position. The ids came back in the backend's `index_number` order over a different set of rows, so a row could be handed another track's URL and any track past the end of the shorter list was never started. On Android that loop also stopped wherever the webview was suspended. - `album_id` is what `OfflineRepository::get_items` joins a track to its album on, so a track that did download stayed invisible under its album offline — the same missing link seen from the other side. The operation now belongs to Rust end to end: - `HybridRepository::get_album_tracks` asks the server what the album contains. Cache-first `get_items` is right for browsing and wrong for deciding what to download; it errors offline so the caller falls back to the ungated local catalog, keeping the queue-while-offline flow. - `queue_album_tracks` writes the album link onto every track it queues, and creates an `items` row for tracks the cache has never seen. - Stream URLs resolve here, through the existing reconnect resolver, now scoped to the rows just queued so one album cannot start every unrelated pending row. Only the album id crosses the IPC boundary. - `album_file_names` gives each track its own file. A title repeated inside one album (deluxe edition, two discs) mapped to one path, so those downloads overwrote each other. Re-tapping download on a broken album heals it: missing tracks are queued and the tracks already on disk get their link. `download_series`/`download_season` still derive their episode lists from the cache the same way and want the same treatment. DR-173, UT-170..172. Rust 673 tests, frontend 975 tests, svelte-check and check:boundary clean. Note: this tree is shared with a concurrent session. Only the files above are committed; docs/traceability.md is left to be regenerated once that work lands.	2026-08-16 09:20:32 +02:00
dtourolle	82b6982d68	fix(player): use a speedometer icon for the streaming quality selector ... The bitrate ceiling button reused a cloud-download glyph, which read as a download action rather than a bandwidth setting.	2026-08-16 08:25:43 +02:00
dtourolle	3363ff7f08	Merge branch 'master' into worktree-mosaic-library ... # Conflicts: # scripts/extract-traces.test.ts	2026-08-16 00:51:46 +02:00
dtourolle	f46d7bf676	fix(player): make native Android video opt-in again — it shipped as audio with no picture ... DR-161 flipped experimentalNativeVideo on by default so picture-in-picture could shrink a real video surface. On a device that shipped sound with a blank screen. The decode path was never at fault. Logcat shows ExoPlayer running and feeding a live SurfaceView with an active BufferQueue. The compositing was: the SurfaceView sits behind the WebView, and the step that clears the opaque layers above it never took effect — `WebView transparent = false` is logged, `= true` never appears. The video was rendering correctly the whole time, behind an opaque page. This is precisely the defect the flag existed to contain; VideoPlayer.scrubRegression.test.ts had already recorded that "the native SurfaceView has never been visible through the webview". Enabling it by default shipped a verified decode path on top of an unverified display path. Reverting costs nothing that matters: PiP does not depend on it — DR-160 drives PiP from the WebView <video> — and working video outranks PiP showing a native surface. The flag stays in Settings, now described as incomplete rather than as a performance win, so anyone helping test it still can. Fixing the compositing is the prerequisite for trying this default again (DR-172).	2026-08-16 00:42:56 +02:00
dtourolle	7e1f0e0547	Merge branch 'master' into worktree-mosaic-library ... # Conflicts: # docs/traceability.md	2026-08-16 00:06:15 +02:00
dtourolle	e015c4c9b1	Merge branch 'master' into worktree-mosaic-library ... Renumbers the mosaic's requirement IDs out of the way of the download work that landed on master in parallel: it had already claimed DR-163/DR-164 and UT-162, so the mosaic layout is now DR-172, the library favourites scope DR-173, and its composition test UT-167. Note for the download branch: its UT-162..UT-165 rows trace to DR-163..DR-166, none of which are defined in requirements.md — that branch defined DR-167..171 instead. Those references are orphaned and want a look; nothing here touches them.	2026-08-16 00:04:26 +02:00
dtourolle	7387f35c7e	docs(player): correct the stale "native video defaults to off" comments ... DR-161 made `experimentalNativeVideo` default to on, but three comments still described the pre-flip world and one of them was load-bearing: - `nativeVideo.ts` labelled the store "Default off" directly above a `load()` that returns true when nothing is stored. - The two PiP comments explained themselves as "what makes PiP work in the shipping configuration", which stopped being true when Android started shrinking the real ExoPlayer surface. They still describe the Linux path and the flag-off case, so they say that instead. - `video_audio_codecs` justified its narrow codec list with "video does not play through ExoPlayer", which is no longer so on Android. The narrow list is still right, for a different reason now recorded: the flag is a user setting and a download outlives it, so only the intersection holds on both sides of the switch. DR-171 carries the same caveat. No behaviour change.	2026-08-16 00:00:10 +02:00
dtourolle	0861523015	feat(library,home): lay libraries out as a mosaic, with favourites per category ... The library overview and the home shortcut strip showed artwork of three different shapes — square music covers, 16:9 library backdrops, 2:3 posters — in grids that pick one box and crop everything to it. The home strip said so in a comment: it forced `aspect="video"` on music libraries so the row would line up, which lined it up by cutting the covers down. Both surfaces are now justified mosaics: rows share one height and each tile is as wide as its own artwork. `layoutMosaic` is a pure module — it packs tiles until the height needed to fill the container drops to the target, justifies the row by absorbing the rounding remainder into its widest tile, and deliberately leaves the last row unstretched so one leftover tile does not inflate into a banner. The component supplies only what the DOM knows: the measured container width, and the artwork's *decoded* aspect ratio (via a new `onNaturalSize` on CachedImage), committed in one debounced batch so the grid does not reshuffle once per image as artwork lands. Favourites gain a tile per category beside the library it belongs to, alongside the existing cross-library entry. Which collection type maps to which category is Jellyfin vocabulary, so it is derived in Rust — `SearchScope::for_collection_type`, stamped onto every `Library` by a new constructor and carried over as an optional `favoritesScope`. Deriving it in Svelte would have rebuilt the exact leak `SearchScope::item_types` was extracted to close. A category shows one tile however many libraries share it, and a library kind favourites do not carve up (Live TV, channels, books) gets none. Also corrects the requirements-count test, which the UR-074 commit left one behind. Spec: docs/specs/library-mosaic.md TRACES: UR-075, UR-067 | DR-163, DR-164 | UT-158..UT-162	2026-08-15 23:57:09 +02:00
dtourolle	ac4fccd499	fix(downloads,playback): re-encode undecodable audio and carry the media source through ... Work from a parallel session in the same working tree, committed here so the branch is not left half-written. Attribution note: authored in a concurrent Claude session, not by the author of the preceding commit. - DR-171: a downloaded video keeps audio the device can actually decode. `original` quality asked for a straight copy, so an E-AC-3/AC-3/DTS/TrueHD track came down untouched and the webview had nothing to play it with. - `get_video_download_url` gains the media source, so the URL is built against the source actually chosen rather than the item's default. - Device profile and repository plumbing updated to match. Verified green as a whole: 656 Rust tests, 945 frontend tests, svelte-check clean.	2026-08-15 23:54:00 +02:00
dtourolle	d49d027020	docs(player): allocate UR-074/DR-162 for the streaming bitrate cap ... The feature shipped tagged against DR-160, which a parallel session had claimed for picture-in-picture in the meantime. Renumbered to DR-162 across the Rust and frontend TRACES comments (the PiP tags in VideoPlayer.svelte, pictureInPicture.ts and nativeVideo.ts keep DR-160) and regenerated bindings.ts. Adds the requirement rows the tags point at: UR-074 for the user need, and DR-162 covering why the cap has to reach the PlaybackInfo negotiation and not only the transcode URL, why the ceiling is process-wide, and why the Settings default persists while the in-player override does not. Notes that this gives UR-070 its resume-at-the-same-point mechanism while the server-offered rendition list that requirement also asks for stays proposed. UT-156/157 record what the tests pin. docs/specs/streaming-bitrate-cap.md carries the layer assignment — the step definitions, the video/audio split, the resolution pairing and the reload decision are all Rust; the frontend holds a serde token and the labels it was handed. TRACES: UR-074 | DR-162 | UT-156, UT-157	2026-08-15 16:39:53 +02:00
dtourolle	dda2ff86a3	feat(player): cap streaming bandwidth with a user-chosen bitrate ceiling ... Video streams were opened at a fixed allowance nobody could change: MaxStreamingBitrate=20000000/VideoBitrate=18000000 on the HLS transcode URL, 20 Mbps in the PlaybackInfo negotiation, and a 999999999 device profile that let the server direct-play a source of any size. On a metered or slow connection there was no way to spend less. StreamingQuality is a ladder of bandwidth ceilings — Original, 20/10/8/ 4/2/1 Mbps and 720 kbps — where a step bundles the total ceiling, the audio share of it and the resolution that budget can carry. Those numbers are Jellyfin encoding vocabulary, so they live in Rust and the frontend only names a variant; labels and details come back over IPC from player_get_streaming_qualities, the same arrangement as the EQ presets. The cap has to reach the *negotiation*, not just the transcode URL: max_static_bitrate in the device profile is what makes the server refuse to direct-play a file fatter than the cap, and without it a 30 Mbps remux is handed over untouched and every URL parameter downstream is moot. So it is applied at all four places that decide bandwidth — the HLS URL builder, PlaybackInfo, the Live TV stream, and the background-audio handoff (which takes the lower of the cap and its own 384 kbps). Video bitrate is the total minus the audio share so the two together honour the ceiling rather than overshooting it. The ceiling is process-wide rather than a repository field: it is a preference about this device's connection, must survive a repository rebuilt on re-login, and every URL builder plus the negotiation have to agree on it or the cap leaks. Same shape as INCLUDE_CATALOG_BROWSE. Two ways in. Settings holds the durable default, persisted to app_settings and restored at startup — unlike the rest of VideoSettings, because a limit set for a metered connection that silently reverts to uncapped on the next launch spends the user's data with no changed setting to see. The in-player menu is the "this film, this connection" override: a cap is a property of the stream the server is producing, so it cannot apply to one already in flight — player_set_stream_quality re-opens the stream at the new quality and resumes at the current position, reloading the native backend itself and handing HTML5 a URL for the same reloadSource primitive the audio-track switch uses. Tests pin the URL parameters at a capped and an uncapped step, the handoff taking the lower of the two, the ladder's internal consistency (video + audio == cap, resolution descending with bitrate) and the persisted token's round trip. The ceiling is process-wide, so the tests that depend on it serialise on a guard that restores the default. TRACES: UR-074 | DR-160 | UT-156, UT-157	2026-08-15 16:34:56 +02:00
dtourolle	9f5f57cba4	fix(ui,player): scroll restore, immersive fullscreen, watched toggle, handoff timeline, PiP ... Batch of reported bugs and enhancements. UI - Pages no longer inherit the previous page's scroll position (DR-156, UR-072). The shell keeps its scrollers alive across navigation by design, so the element never remounts and its scrollTop survived the route change; SvelteKit restores window scroll, which this app never uses. ScrollMemory records the offset per route and per container: forward moves reset to the top, Back restores where the route was left. - Season header stacks on narrow screens, and the title span gets min-w-0 so it actually truncates instead of overflowing under the action buttons. - Favourites gets a labelled tile at the head of the library grid rather than only an unlabelled heart icon in the header. Playback - Full-screen video on Android hides the system bars (DR-157, UR-066). requestFullscreen() cannot touch the Activity window from inside a WebView, so the control did nothing visible while the bars stayed painted over the video. ImmersiveModeBridge hides them, restored on exit, Escape and teardown. - Background-audio handoff stops leaking its relative timeline (DR-159). background_audio_base was a display-only correction applied in two places while progress reports to Jellyfin, the frontend and media3's own seeks all worked in the relative timeline treating it as absolute — each crossing losing exactly `base` seconds. The conversion now happens once, in the position tick, and inbound seeks resolve through seek_absolute, which re-opens the stream at the requested position because the handoff transcode cannot seek. - Picture-in-picture works on the path that actually plays video (DR-160). canEnterPip demanded a native ExoPlayer surface, but that path is behind a flag defaulting to off, so PiP could never engage. It now accepts the WebView <video> too, keeping the WebView visible and routing play/pause to the element. - Native video is now the default so PiP has a real surface (DR-161). The scrub-regression tests pinned the flag-off path implicitly; they now mock it off explicitly. The native scrub/seek path is not covered by the suite and needs device verification. Watched state - Watched toggle on the episode row, season header, series and movie hero, and the Episode Focus View (DR-158, UR-073). Both backend halves already existed with no caller. storage_set_watched covers a container's episodes so the toggle is honest offline, and QueuedOp::MarkUnplayed gives the sync queue the missing direction. Release - Fix the Android versionCode floor (set-version.sh). v0.5.2 shipped code 5002 under an earlier minor*1000 scheme, but the current minor*100 formula yields 1502 for that version and 1503 for 0.5.3 — so every 0.5.x release built from it was an un-installable downgrade for anyone already on v0.5.2. Widened to 10000 + major*1000000 + minor*1000 + patch (0.5.3 -> 15003). - Bump to 0.5.3.	2026-08-15 16:26:31 +02:00
dtourolleandClaude Opus 5	ba5fd55204	fix(sync): mirror the server's watch position so resume crosses devices (DR-155) ... The resume check reads the local user_data row and nothing else, but mirror_user_data -- the only path by which server UserData lands in that table -- mirrored is_favorite alone, and returned early whenever that field was absent, which is exactly the shape of an ordinary watched episode. playback_position_ticks was therefore write-only from this device's perspective: watch 40 minutes in a browser, open JellyTau, and it resumed from whatever this device last saw, or offered no resume at all. Same user-visible symptom as the Android bug fixed earlier on this branch, from an unrelated cause -- which is why resume read as broadly flaky rather than as one defect. The mirror now carries the position alongside the favourite flag under the same pending_sync = 0 conflict rule, so a local position still waiting to be pushed is never pulled backwards by a server that has not yet heard where we got to. COALESCE(excluded.x, user_data.x) keeps the stored value for a field the server omitted rather than nulling it, and a row with neither field is still skipped rather than fabricated as zeroes. Mirroring alone was not sufficient. get_item -- the call the player route makes -- returned the cached copy on a hit and never consulted the server, so for an already-cached item the mirror never ran. It now refreshes in the background on a cache hit via race_with_refresh, the reusable form of what get_items already did inline. That asymmetry is why browsing a season picked up other devices' state while opening the episode directly did not. The refreshed value lands for the next read; the cache-first race still answers immediately. The DR/total counts in extract-traces.test.ts are updated for DR-154 and DR-155 -- that edit is the test's intended signal that the CI gate's denominator is live rather than frozen. Verified red->green in the jellytau-builder image: both new tests failed before the fix. Full Rust suite passes (634), cargo fmt clean, clippy adds no new warnings; frontend suite (933) and svelte-check clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 22:14:20 +02:00
dtourolleandClaude Opus 5	1f32e4040b	Merge branch 'fix/home-library-card-heights' from origin ... Local and remote had both advanced two commits from 3619f71 with no overlapping files: remote: uniform card heights; resume after furthest-watched episode local: Android native-path resume; queued watch-position sync (DR-154) Merged cleanly with no conflicts. The series_progress policy tests pass against the merged file (19/19). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 19:21:18 +02:00