68 Commits

Include renames

Author	SHA1	Message	Date
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	c18d79c656	fix(android): stop background audio rewinding to where it started ... A video handed off to background audio (UR-040) streams a live mp3 transcode over plain HTTP. That response is chunked, so there is no Content-Length, and a live encode carries no Xing header, so the extractor establishes no duration — on device every position tick reads "<position> / 0.0". ProgressiveMediaPeriod.configureRetry resumes a failed load in place only when the content length is known or the seek map has a duration. With neither it assumes the source is live, sets pendingDeferredRetry, and when the sample queues next run dry resets them and re-requests the URL from offset 0. Our URL carries StartTimeTicks = the handoff point, so "offset 0" is where audio-only mode began: a transient load error armed a retry that fired minutes later, when the buffer finally drained, and playback resumed at the handoff point and ran on from there. A successful retry raises no error and ends nothing, so neither arm of DR-129 was consulted and no discontinuity handler existed — the only trace was a position that went backwards, which is why it read as random, and why the two earlier fixes for the same symptom (DR-129's phantom end, DR-159's relative-timeline leak) left it standing. A retry that can only restart the stream is worth less than no retry at all. player_retry_restarts_stream marks a Remote audio-only video item, loadWithMetadata carries the answer to Kotlin, and the pure StreamRetryDecision holds it for a DefaultLoadErrorHandlingPolicy that returns C.TIME_UNSET — making onLoadError answer DONT_RETRY_FATAL before it reaches configureRetry. The rewind becomes a recoverable error, which recoverable_error_resume already answers by re-opening at the position playback reached, StartTimeTicks rewritten so the selected audio track survives. Every other source keeps the player's retry: a static file and an HLS playlist declare their timeline and are resumed where the load stopped. onPositionDiscontinuity is added for its log line alone, loud for DISCONTINUITY_REASON_INTERNAL, which is the rewind's own signature. Verified on device (FP5), same procedure both runs — handoff, 60s to fill the buffer, a 45s radio outage: before 13:54:52 BUFFERING, then "Media ready! Duration: -9.22e15" (C.TIME_UNSET) and position 1165.4s -> 840.349s, exactly the handoff base, 3.5 minutes after the outage with nothing logged between after 14:05:08 "declining the player's retry", playback undisturbed off the buffer for 69s (a fatal load error is only raised when the renderer next needs data), then ERROR_CODE_IO_NETWORK_CONNECTION_FAILED -> re-opening at 785.6s -> READY, and no rewind in the following 7 min Kotlin tests run with ./gradlew :app:testUniversalDebugUnitTest. TRACES: UR-040, UR-004 | DR-203 | UT-200	2026-08-19 17:29:31 +02:00
dtourolle	caebf2d139	fix(android): keep the display awake while video plays ... Android counts its display timeout from the last user input, and watching something is exactly the case where there is none — so the screen dimmed and slept mid-playback unless the user kept tapping it. Nothing held it. FLAG_KEEP_SCREEN_ON appeared nowhere in the app, and neither renderer supplies a hold for free: ExoPlayer's setWakeMode is a CPU/wifi wake lock that says nothing about the display, and it draws into the TextureView we own (DR-192) rather than media3's PlayerView, which is the widget that would otherwise set keepScreenOn itself; the webview <video> path is no better, because the display wake lock Chrome takes for video lives in the browser layer and not in an embedded WebView. ScreenWakeManager toggles FLAG_KEEP_SCREEN_ON on the Activity window — window scoped, so it stops applying the moment the app is not visible and cannot outlive a crash the way an acquired PowerManager.WakeLock can, and it needs no permission. The two rendering paths are independent holders OR-ed in the pure ScreenWakeState: the native path follows onIsPlayingChanged plus surface teardown, so the hold tracks what ExoPlayer reports rather than what the UI intends, and the webview path reuses the setHtml5VideoState report the frontend already sends for PiP. Audio is deliberately not a holder — screen-off music is the point of that path. Also the repo's first Kotlin JVM unit tests: ScreenWakeState is framework-free, so the decision is testable off-device with ./gradlew :app:testUniversalDebugUnitTest (note the variant — plain testDebugUnitTest is ambiguous here). sync-android -sources.sh mirrors src/test into the gen tree alongside the main sources. TRACES: UR-003, UR-004 | DR-202 | UT-199	2026-08-18 14:56:08 +02:00
dtourolle	6dfc6b259a	fix(player): lockscreen skip scrubs instead of advancing in background audio ... onSkipToNext/onSkipToPrevious forwarded a bare next/previous to Rust, which always advanced the queue. Correct for music, wrong for a video whose audio is running through a background-audio handoff (UR-040): pressing skip to re-hear a line jumped to the next episode instead of scrubbing. resolve_skip_action in player/seek.rs maps the command to Advance or SeekTo, and is_background_audio_active() is the whole test — the handoff exists only for video, and an episode played through it reports MediaType::Audio, so media type cannot distinguish the case. Forward 30s, back 10s, both clamped to [0, duration] so a skip near either end cannot seek negative or read as EOF and advance. Routed through the same spawn-then-seek_absolute path as the scrubber, because a handoff seek re-opens the stream and must not run under the blocking lock (DR-159). Kotlin keeps sending the opaque command; it only gains FAST_FORWARD/ REWIND in the PlaybackStateCompat so the system stops drawing skip arrows for a control that scrubs. The remote-volume action block is deliberately untouched: the handoff never applies to cast sessions, where skip really does mean advance. Tests written first and watched fail (left: Advance, right: SeekTo). 706 Rust tests pass, clippy 0, coverage 90%.	2026-08-16 23:54:43 +02:00
dtourolle	88e15e3e12	merge: Android runtime security (B1, B3) ... Correct the POST_NOTIFICATIONS mechanism: the lockscreen notification is exempt because of the MediaSession token, not because it belongs to a foreground service — FGS notifications are explicitly NOT exempt. So no permission prompt and no checkSelfPermission gate; instead both notification builders bind the token once and log loudly if it is ever null, turning a silent failure into a logcat line. Stop the webview undoing the network security config: mixedContentMode COMPATIBILITY, allowFileAccess/allowContentAccess false. Conflict resolution: this branch's DR-198 collided with the Tauri branch's, so it was renumbered DR-200 (3 TRACES in JellyTauPlaybackService.kt and the UR-006 matrix row updated). DR-199 was uncontested. Pinned counts summed to DR 191 / total 334; UR-071 takes both DR-198 and DR-199.	2026-08-16 23:03:29 +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	2d21f092d5	fix(android): stop the webview undoing the network security config ... MainActivity set mixedContentMode = MIXED_CONTENT_ALWAYS_ALLOW together with allowFileAccess/allowContentAccess = true, which is a blanket cleartext opt-in reached by hand — the exact thing network_security_config.xml exists to prevent and its own comment warns against. Nothing needed any of the three: - file:// is never loaded. Cached thumbnails go through convertFileSrc, which on Android resolves to http://asset.localhost/... and is answered by wry's request interceptor rather than the filesystem; downloaded media goes over the loopback HTTP server (DR-137), which exists precisely because the asset/file route cannot stream a large file. - content:// is never loaded. The manifest's FileProvider is for outbound share intents, not webview navigation. - Mixed content never arises. Tauri serves the UI from http://tauri.localhost (use_https_scheme defaults false and is not set), and both 127.0.0.1 and asset.localhost are loopback/.localhost origins Chromium treats as potentially trustworthy. A plain-HTTP remote server would be mixed content, but the network security config already rejects it first — so ALWAYS_ALLOW bought nothing. COMPATIBILITY_MODE rather than NEVER_ALLOW is a deliberate hedge: the platform default at targetSdk 21+ is NEVER_ALLOW, so this is still one step looser, and it keeps passive content working if the analysis missed a path. The two files now cross-reference each other so the pair cannot drift apart again. Also records why POST_NOTIFICATIONS is declared but never requested. An audit read the missing runtime request as a threat to the lockscreen controls; it is not. A foreground-service notification is explicitly NOT exempt, but a media-session one is, and the platform predicate (Notification.isMediaNotification) requires MediaStyle AND a non-null session token. Confirmed on device: appops POST_NOTIFICATION: ignore with the transport notification live. So no permission prompt is added and startForeground stays ungated — a guard there would trade a cosmetic problem for the "did not then call Service.startForeground()" kill. What is added is the guard matching the real precondition: both builders bind the token once and log an error if it is ever null, since SystemUI's media carousel is gated on the same predicate and a token-less notification loses the lockscreen controls entirely, silently. TRACES: UR-006, UR-071 | DR-198, DR-199	2026-08-16 22:59:47 +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	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	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	521acc75fd	build(android): add a side-by-side release build for validating R8 ... R8 has broken release APKs here before by stripping the JNI-loaded player and security classes, and the only way to reproduce that was to build with the real signing key and clobber the install you actually use. `./scripts/build-and-deploy.sh release --device --debug` now builds a fully minified release APK — exactly what ships — into the .debug applicationId slot, signed with the local debug keystore: release com.dtourolle.jellytau 0.5.5 release --debug com.dtourolle.jellytau.debug 0.5.5-debug-release debug com.dtourolle.jellytau.debug 0.5.5-debug It shares the applicationId *and* the signature with the plain debug build, so the two replace each other cleanly rather than colliding, and the versionName suffix says which is currently installed. No real key is needed, so the side-by-side path deliberately skips write-keystore-properties.sh. The flag reaches Gradle as JT_SIDE_BY_SIDE=1. CI never sets it, and the release manifest merges byte-identical without it — verified both ways through processUniversalReleaseMainManifest. deploy-android.sh and build-and-deploy.sh learned the flag too, since the APK path is unchanged but the package to launch is not.	2026-08-16 10:42:59 +02:00
dtourolle	2cc39cd7fd	build(android): install the debug build alongside release as its own app ... Testing a debug build meant uninstalling the real one first: same applicationId signed with a different key is INSTALL_FAILED_UPDATE_ INCOMPATIBLE, so every experiment cost the app's settings, credentials and offline cache. The debug build type now carries applicationIdSuffix ".debug" and versionNameSuffix "-debug", so it installs as com.dtourolle.jellytau.debug ("JellyTau Debug", 0.5.5-debug) with its own data directory — two independent apps on one device. Only the *application* id is suffixed. Kotlin classes stay in the `namespace` package com.dtourolle.jellytau, so the JNI loadClass lookups in player/android/mod.rs, the manifest <service> entry and the R8 keep rules are untouched, and the FileProvider authority was already ${applicationId}-relative. Launcher names come from the appLabel / activityLabel manifestPlaceholders rather than resValue, which would collide with Tauri's generated strings.xml; release resolves them back to @string/app_name and merges byte-identical. deploy-android.sh reports the target package and explains an UPDATE_INCOMPATIBLE failure instead of leaving it raw; logcat.sh takes a debug|release argument (it was filtering on com.jellytau.app, a package that has never existed) and attaches by pid when the app is running. Verified: aapt2 badging on the built APK reports com.dtourolle.jellytau.debug / 0.5.5-debug / "JellyTau Debug", and the release manifest merge is unchanged.	2026-08-16 10:36:48 +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	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	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	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	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	a5535f2941	fix(downloads): stop libraries mixing, make pause/resume real, reap partials, end bitrate corruption ... Four defects behind "downloads still flaky", each with its own cause. Libraries mixed their media (DR-167). Cached items carry no link back to their library — library_id and parent_id are NULL on every row — so the library branch of get_downloaded_items matched `EXISTS (SELECT 1 FROM libraries WHERE id = ?)`, which asserts only that the library exists and never constrains the item to it. Opening any downloaded library listed every downloaded top-level item on the server: films under Music, albums under TV. The query deciding which libraries appear already had the right rule, so the two disagreed about the same question; that collection_type <-> item_type mapping is now one constant used by both. Pause and resume did nothing (DR-168). pause_download wrote status = 'paused' and stopped there — no cancellation existed anywhere in the download stack, so the streaming task ran on and overwrote the row with completed/failed when it finished. The row flicked to "paused" and undid itself. resume_download had the mirror defect: it flipped the row to 'pending' without pumping, and the pump is not a poller, so a resumed download sat until some unrelated event pumped the queue. Adds a per-download stop flag the worker reads between chunks and on retry, returning Stopped — not retryable, not recorded as a failure, and the .part file is kept because that is what the resume continues from. Registering returns a fresh flag so a resumed download does not inherit the pause that stopped it. Cancel and clear_stale_downloads signal it too, so neither deletes a file still being written. Partial files were never reaped (DR-169). The worker named its sidecar with with_extension("part"), which replaces: movie.mp4 became movie.part. Every cleanup path deleted "{file_path}.part" — movie.mp4.part. They never matched, so the partial of every cancelled or failed download stayed on disk forever, invisible to disk-usage totals because no row pointed at it. One partial_path helper now serves the writer and the cleaners. Bitrate downloads corrupted themselves (DR-170). Only `original` asks for Static=true; every other rung requests a transcode, which Jellyfin serves chunked with no Content-Length and cannot byte-seek — it ignores Range and answers 200 with the whole stream, not 206 with the tail. The worker sent the header whenever a .part existed and appended the body regardless, so each retry concatenated another full copy onto what was on disk. The file grew past its real size and would not play, which is why bitrate downloads stayed broken after the videoBitRate casing fix corrected the request. resume_offset now lets the response decide: append only on 206, otherwise truncate and take it from the top. docs/requirements.md also carries DR-171/UT-166, written by a parallel session working in the same tree; its code lands separately.	2026-08-15 23:52:02 +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	50934e2ac6	ci(android): ship Gradle in the builder image instead of downloading it ... The release APK job died at the Gradle wrapper step, after the 11-minute Rust compile had already succeeded: Downloading https://services.gradle.org/distributions/gradle-8.14.3-bin.zip java.net.SocketException: Unexpected end of file from server `tauri android init` regenerates gen/android with a wrapper pointing at services.gradle.org, so every Android job re-downloaded ~130MB of Gradle at build time. That is slow on a good day and a hard build failure when the CDN drops the connection mid-transfer. It was also a standing violation of the rule that every build tool must already live in the builder image. Dockerfile.builder installs Gradle 8.14.3, keeping both the unpacked distribution (on PATH) and the original zip under /opt/gradle/dist. A `gradle --version` smoke-test fails the image build on a bad version rather than letting CI discover it. sync-android-sources.sh then repoints the regenerated wrapper at that local zip, which is the established place for fixing up the generated project. It parses the version the wrapper actually requests, so a future Tauri Gradle bump logs "not in image, will download" instead of pointing at a missing file. On dev machines /opt/gradle/dist does not exist and the properties file is left untouched. Verified by running the project's own wrapper jar inside a network namespace with no connectivity: it resolved and unpacked the local zip to 100% and proceeded into build-script evaluation. Note: this is inert until the builder image is rebuilt and pushed (scripts/build-builder-image.sh). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 07:47:43 +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	3619f71aba	build: make the git tag the single source of truth for the version (DR-153) ... The version lived in four files — package.json, tauri.conf.json, Cargo.toml and Cargo.lock — that had to be hand-edited in lockstep, and the release workflow rewrote exactly one of them. A tagged build therefore produced an installer named for the tag wrapped around package metadata naming the previous release, and the Linux job, which had no version step at all, shipped whatever happened to be committed. scripts/set-version.sh now writes all four from one argument and is the only thing that does. Every release job calls it with the tag, including the Linux job that was missing one. The committed versions become a placeholder for dev builds rather than something to maintain by hand. The Android versionCode moves into the same script, unchanged in formula (1000 + major*10000 + minor*100 + patch). It stays inline-documented because the reasoning is not obvious: builds already in the field shipped code 1000, and Android refuses an update whose code is lower than the installed one, so a formula that can emit a smaller number for a newer release bricks updates irreversibly. UT-150 asserts that property directly — monotonic across an upgrade sequence, and always above the floor. Two edge cases the previous inline version got wrong: - A prerelease tag (v0.6.0-rc1) made $(( 0-rc1 )) abort the step under set -e. The suffix is stripped before the arithmetic; the manifests keep it. - CI passes "${GITHUB_REF#refs/tags/}" unconditionally, which on a branch build is still a full ref. That reached the validator verbatim and would have failed every untagged Android build; a non-tag ref now falls back to git describe. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 21:21:58 +02:00
dtourolleandClaude Opus 5	5fa74d9e34	docs: renumber to DR-150/151/152 after rebase onto master ... master landed DR-148 and DR-149 for unrelated audio-decode work (0.4.7/0.4.8) while this branch was in flight, and both sides claimed the same two IDs. The native-video requirements move to DR-150 (native rendering behind the flag), DR-151 (the severed SurfaceView attach chain) and DR-152 (capabilities reported by Rust). UT-090 was likewise already taken by the seek-bar test, so the adapter selection test moves to UT-149 and is registered in the table. The spec header also cited DR-023/DR-024, which are the subtitle and audio-track selection UI requirements — unrelated to this work. Corrected, with a note so the wrong IDs are not reintroduced from the draft. extract-traces.test.ts asserts the live requirement counts on purpose, so adding three DRs moves DR 144→147 and total 282→285. Subtitles on the native path are not a regression from this branch: master's 6a712c4 already fixed the root cause (MediaItem.subtitles was hardcoded to vec![], so ExoPlayer always received zero SubtitleConfigurations) and that fix is now underneath these commits. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 20:57:58 +02:00
dtourolle	acddcdd6fa	fix(playback): force a transcode when the webview cannot decode the audio (DR-149, 0.4.8) ... Advertising a webview-shaped profile (DR-148) was necessary but not sufficient. Probing the server directly showed Jellyfin 10.11.5 enforces a DirectPlayProfile's Container and VideoCodec — excluding either returns SupportsDirectPlay:false with TranscodeReasons=ContainerNotSupported / VideoCodecNotSupported — but ignores its AudioCodec entirely: an E-AC-3 track is still offered for direct play against a profile listing only aac,flac,mp3,opus,vorbis. Neither a VideoAudio CodecProfile forbidding the codec nor MaxAudioChannels:2 against a 6-channel track changes the answer, so no profile the client can send fixes this and the picture plays silent. The client therefore stops delegating a question it can answer itself. The negotiated source's audio is checked against what the webview decodes, and an undecodable track forces the existing h264/aac HLS transcode regardless of the server calling direct play fine; direct_play and needs_transcoding are corrected to match so the frontend and the reporting path agree with the URL actually used. The track judged is the one that would be served — the default, else the first — since a supported track further down is not the one that plays. A source with no audio, or a codec the server did not name, is left alone rather than transcoded on a guess. Test-first: the new tests failed against the old behaviour before the decision existed. Verified on a motorola edge 30 by the audio HAL, not by ear — the same E-AC-3 episode logged isMusicActive=true once and 58 ACDB-LOADER lines under this build, against 0 and 0 on 0.4.6, where an AAC file in the same session produced 16 and 116. No FATAL EXCEPTION, so R8 on the signed release build is unaffected. Also carries in-flight subtitle-track work authored in a parallel session (subtitleTracks, VideoPlayer, player/media, bindings) at the user's request, so the tag matches the APK verified on device.	2026-08-11 20:07:11 +02:00
dtourolle	2c3955914e	fix(playback): advertise only webview-decodable audio for video (DR-148, 0.4.7) ... The audio codec list sent to Jellyfin comes from MediaCodecList, which describes ExoPlayer — but video does not play through ExoPlayer. Android force-renders every video in the webview <video> element (the interim override in VideoPlayer.svelte) and Linux always has, and Chromium/WebKit decode a far narrower set than the platform does. A motorola edge 30 ships /vendor/etc/media_codecs_dolby_audio.xml, so it reported ac3,eac3; the server direct-played an E-AC-3 track with static=true and the webview built a video decoder and no audio decoder at all — full picture, no sound. The defect is triggered by capability rather than the lack of it, which is why a Fairphone and an Honor tablet play the same file on the same build: without the Dolby decoder they never claim the codec, so the server transcodes to AAC. Confirmed by A/B on the failing device — hevc+eac3 silent, hevc+aac audible, same session, same profile, same direct-play path, audio codec the only variable. video_audio_codecs narrows the platform list to the webview-decodable set for the video direct-play profile only. Audio-only playback really is the native player's, so that profile keeps the full list rather than transcoding music that plays perfectly well. A list with nothing decodable still claims aac, since a profile claiming nothing invites the server to give up instead of transcoding. The video codec list is deliberately untouched: HEVC direct-plays through the webview correctly, so the constraint is specific to audio. Test-first: the tests failed against the old behaviour before the filter existed, including the case built from the phone's real codec list. The requirement-count assertion in extract-traces.test.ts moves 280 -> 281 for the added DR, which is the deliberate edit that test exists to force. Not yet verified on device — the 0.4.7 APK was still building.	2026-08-11 19:13:46 +02:00
dtourolle	1b70926c36	feat(offline): play downloaded video, and drain the offline sync queue (0.4.6) ... Bundles this session's work plus the concurrent search/offline/player changes. Every gate passes on the combined tree: 885 frontend tests, 610 Rust tests, clippy clean, boundary clean, trace coverage 86%. Offline video playback — four separate defects, each of which alone stopped it: DR-133 A completed download's file_path is already absolute (the worker rewrites it on completion), but the player rooted it a second time and handed the webview /data/user/0/app//data/user/0/app/videos/x.mp4. DR-134 The asset protocol was never enabled: no protocol-asset feature and no assetProtocol config, so convertFileSrc produced URLs nothing answered. Also silently defeated the cached-thumbnail path, which fails soft to the server copy and hid it whenever the server was reachable. DR-137 Tauri's asset protocol answers a range-less request by reading the whole file into memory, and only advertises Accept-Ranges from inside its range branch, so the first request never learns ranges exist. Chromium gave up with PIPELINE_ERROR_READ after ~31s. Local media is now served by a loopback HTTP server: bounded 4 MiB chunks streamed from the file handle, every response length-delimited, and a range-less request answered with one chunk rather than the file. Confined by a per-session token and to the app data directory, because loopback is shared between apps on Android. DR-138 Release builds set usesCleartextTraffic=false, so Android rejected the request to that server before any I/O. A network-security-config exempts 127.0.0.1 only; a remote server must still be HTTPS. Downloads: DR-135 download_item never records media_type and the reconnect resolver read that NULL as 'audio', so a movie queued from a media card had its URL resolved by get_audio_stream_url and completed as an audio-only transcode. The item's own type now decides. DR-136 Rows already downloaded that way are requeued on reconnect, since prevention alone leaves them reading "downloaded" and still unplayable. Known limitation: a download taken at `original` quality is a byte copy of the source, so it can be any container. One such file is an AVI holding XVID, which the webview cannot play in any case — the media server serves it correctly and Chromium refuses it. That needs either a transcoded download preset or the native ExoPlayer surface work, and is not addressed here. Also fixes two ID collisions between concurrent work: DR-143 defined twice (search vs offline gate) and UT-131 defined twice (Episode Focus hero vs channel cap). The search requirement is now DR-147 and the channel-cap test UT-141, with their code references and matrix rows updated.	2026-08-09 16:38:07 +02:00
dtourolle	cc7f1cece0	fix(player): play downloaded video offline (DR-133, DR-134) ... Offline video never started: the <video> element reported NETWORK_NO_SOURCE one millisecond after loadstart, which the UI mislabelled as "may need transcoding" even though nothing had been fetched. Two independent causes, both required for playback. The path was doubled. `downloads.file_path` is stored relative to the storage root while a download is queued, but the worker rewrites it to the absolute path it actually wrote once the transfer completes — so a completed row is already rooted. The player's offline branch rooted it a second time, producing /data/user/0/app//data/user/0/app/videos/x.mp4. Audio was unaffected because it resolves the same column through Rust's resolve_local_media_path, which does not re-root. The join is now absolute-aware (POSIX, Windows drive letters, UNC) so rows written before completion still resolve. The asset protocol was never enabled. convertFileSrc rewrites a path to http://asset.localhost/… unconditionally, but Tauri only answers that origin when the protocol-asset cargo feature is compiled in *and* app.security.assetProtocol.enable is set — neither was, so even a correct path resolved to nothing. This also silently defeated the cached-thumbnail path in imageCache, which fails soft to the server copy and so hid the breakage whenever the server was reachable. Scoped to $APPDATA/** — the storage root holding the database, downloads/ and the thumbnail cache — rather than an unrestricted grant. Diagnosed from logcat on device; UT-124 reproduces the doubled path.	2026-08-09 15:05:16 +02:00
dtourolle	30dc3ba7f6	fix(player): recover a failed stream on Linux instead of stopping (DR-130) ... A recoverable player error meant "playback is over": the frontend's error handler stopped the player unconditionally, so a wifi blip killed the track. Android already decides in its JNI callback, but MpvBackend is constructed before PlayerController exists, so its event thread has no controller to ask. So MPV reports the failure and the frontend echoes it into the new player_recover_stream command — the same shape as PlaybackEnded -> player_on_playback_ended, keeping the decision in Rust. The command re-opens the stream where it stopped, with the existing attempt budget and backoff, and returns whether it handled it; only a false answer falls through to the old stop path. Android now reports the errors it has already declined as *unrecoverable*, so the echo never asks the same question twice. TRACES: UR-004, UR-040 | DR-130 | UT-117	2026-08-04 20:15:28 +02:00
dtourolle	62873cab3d	feat(search): answer search from a local index; tier downloads by lifetime ... Search's instant leg read only downloaded items, so with no downloads it returned nothing and every keystroke fell through to a full Recursive=true server query. It now reads the whole synced catalog through the same availability CTE get_items uses, gated on the same include_catalog_browse flag so search and browse cannot diverge. (UR-065, DR-108) Also fixes three defects found while confirming that: - items_fts grew by a full duplicate index every catalog pass. INSERT OR REPLACE fires no AFTER DELETE trigger without recursive_triggers, so the old index row was orphaned, and a TEXT PRIMARY KEY meant the replacement took a fresh rowid and inserted a second entry. Now a real upsert, with migration 021 rebuilding existing indexes. (DR-110) - DELETE FROM items existed nowhere, so server-side deletions never propagated. Adds a post-crawl mark-and-sweep, scoped to crawled types, skipping downloaded items, and refusing to run after a partial crawl because items.parent_id cascades. (DR-110) - The index omitted MusicArtist, Playlist and People, which search groups results by. Adds them plus people_fts (migration 022). (DR-111) Re-indexing moves from a frontend startup call to a Rust background task with a 6h TTL, so a long session no longer searches a stale catalog and a restart no longer forces a crawl regardless of freshness. (DR-109, IR-030) Downloads gain a lifetime tier. Eviction selected every completed row by age with no download_source filter, so hitting the storage limit deleted the oldest download -- typically one saved deliberately for offline -- to make room for a precached track. It now reclaims only 'auto' rows, and expired ones are reclaimed first, before live cache is evicted. (DR-126, DR-127) Downloaded video and audio-only handoffs now play from disk instead of streaming; the video path had never consulted downloads at all. No transcode is involved: MPV runs video=no and ExoPlayer has no surface for an Audio item. (DR-123 in part, DR-128) FTS queries are built as quoted phrases so apostrophes, hyphens and slashes are data rather than operator syntax, and the item-type filter is bound rather than interpolated. Specs: docs/specs/catalog-index-search.md, docs/specs/read-through-media-cache.md Includes concurrently-developed favourites browsing and background-audio stream-end handling; the two workstreams share offline.rs, lib.rs and online.rs, so no subset of files builds independently.	2026-08-04 17:35:17 +02:00
dtourolle	c55ff45692	fix(android): clear the system bars and display cutout (UR-066) ... The bottom nav rendered under the Android navigation bar, and full-screen playback controls spilled into unusable screen edges. It looked device-specific (Motorola bad, Fairphone fine) but every device was equally unpadded — only the intrusion differed: a tall opaque 3-button bar swallows the nav, a thin translucent gesture pill overlaps harmlessly. None of the app's safe-area handling was ever active, for two independent reasons: 1. app.html had no `viewport-fit=cover`, so every `env(safe-area-inset-*)` resolved to 0px — the padding in app.css and BottomUi was a no-op. 2. Android WebView maps only the *display cutout* into `env()`; the status bar and navigation bar are never reported. With enableEdgeToEdge() and targetSdk 36 (enforced from 35, opt-out ignored from 36) the WebView always spans them, so CSS could not learn about them by any route. WindowInsetsBridge now reads `systemBars() | displayCutout()` and publishes `--jt-inset-*` CSS custom properties, both pushed on every inset change (rotation, nav-mode switch, PiP) and pullable via `AndroidInsets.get()` — the pull is required because the first inset pass lands before the document exists and a page load wipes the pushed inline style. app.css folds them with `env()` via `max()` into `--safe-*`, the only thing components may pad from. Exactly one element owns each edge: the shell takes top/left/right, BottomUi takes bottom (inside its surface box, so the colour extends behind the gesture bar), and shellReservesBottomInset hands bottom back to the shell on routes with no bottom UI. The full-screen players inset their control layers only, leaving video and artwork edge-to-edge. The theme's `fitsSystemWindows=true` claimed the opposite of what actually happened — overridden at runtime, ignored at this target SDK — and is removed. Also converts six nested `h-screen`/`min-h-screen` boxes to `h-full`: the shell is `h-screen` *and* inset-padded, so its content box is `100vh - safe-top` and any nested 100vh box overflows by exactly the inset (the library column would have clipped its own BottomUi). A test guards against reintroduction.	2026-08-04 14:45:10 +02:00
dtourolle	58f2506966	feat(series): land on the current episode, not season 1 (UR-062, UR-063, UR-064) ... Opening a series dumped the viewer at the top of season 1, and its Play button played nothing at all: it resolved `$libraryItems[0]` — the first *season* by SortName — and navigated to `/player/<seasonId>`, which the player route bounced straight back to `/library/<seasonId>`. The backend could already answer "where is this viewer in this show": `repository_get_next_up_episodes` has accepted a `series_id` since it was written and no caller had ever passed one. Backend (DR-101, DR-106) - `repository/series_progress.rs`: `pick_current_episode` — in progress, else Next Up, else first unwatched, else the premiere. The third rung is the offline path, where Next Up is always empty. `sort_series_order` puts specials (season 0) after the numbered seasons. - `repository_get_series_episodes` takes over the season fan-out and the flat-series fallback, which were domain knowledge living in the frontend. - `clear_watch_history` maps to Jellyfin's mark-unplayed (recursive over a container, also zeroes resume). Offline it refuses rather than diverging state the next sync would undo. Frontend (DR-102, DR-103, DR-104, DR-107) - Seasons collapse; only the current one is expanded, and the current episode is badged and scrolled into view. - Hero button reads `Resume S2E4` / `Play S1E1` and opens that episode's focus view, where Play commits (ux-flows §5B.5). - Seasons are no longer a destination: `/library/<seasonId>` redirects to `/library/<seriesId>#season-N`, and every inbound link follows. - The "More Episodes" strip spans the whole series, so a season finale offers the next premiere instead of dead-ending (§5B.2). - Clear-history buttons on the series hero and each season header. Routes (DR-105) - `/library/tv` and `/library/movies` absorb their all-titles and genres pages as `?view=` tabs; the four legacy routes redirect. 6 video routes become 2, and `/library/shows/genres` stops being the odd one out. Logic extracted to `seriesNavigation.ts`, `episodeStrip.ts` and `libraryView.ts` so it is unit-tested rather than buried in components. Spec: docs/specs/series-current-episode-navigation.md	2026-08-03 20:37:43 +02:00
dtourolle	a818fee297	fix(player): re-entering a video no longer opens the audio player (DR-100) ... Leaving a video and returning to it rendered the movie/episode in AudioPlayer. Closing a webview-rendered video deliberately emits no "stopped" state (that would break the autoplay handoff), and the direct-play path does not stop the backend on unmount, so the Rust controller still reported that item as its loaded media. Re-entering the route therefore took the "already playing, just show the UI" shortcut, which returns before a stream URL is fetched, and the render fell through to the audio surface. Mostly visible on Android, where video direct-plays; Linux transcodes and stops the backend on unmount. Both decisions move into playerSurface.ts as pure functions: shouldReuseActivePlayback excludes video, so video always takes the full load path and gets its stream URL and resume position; resolvePlayerSurface maps video-without-a-stream-URL to "pending" (spinner) rather than falling through to audio.	2026-08-03 18:12:37 +02:00
dtourolle	9d099268b9	fix(player): make the video seek bar work by touch (DR-099) ... On Android, dragging or tapping the progress bar moved the thumb but playback stayed where it was. Two separate defects, both touch-only, which is why the mouse-driven scrub tests never caught either. 1. Gesture hijack. DR-098 taught handleTouchStart to ignore touches that land on a control, but handleTouchMove kept running. It measures against touchStartX/Y, which that early return leaves at the PREVIOUS gesture's values, so a seek-bar drag produced a huge bogus vertical delta: read as a brightness swipe, it dimmed the screen to the 0.3 floor and fired a spurious play/pause "correction" mid-drag. A gesture is now latched at touchstart (playerGestureActive) and touchmove ignores anything unlatched — re-checking the move target cannot recover a start point that was never recorded. 2. Commit signal. The seek was committed only from `change`, which Android's WebView does not reliably fire for a touch interaction on a range input, so the thumb moved to the tapped position and no seek ever ran. touchend/mouseup now commit too; `input` arms a one-shot latch so whichever release signal arrives first commits and the other is a no-op. seekRelative shares the same commitSeek entry point instead of fabricating a synthetic change event. Tests drive the slider with real touch events (UT-089, UT-090) and fail against the pre-fix component.	2026-08-01 10:41:23 +02:00
dtourolle	b565c4ae6f	fix(player): tap gestures act immediately, no deferral timer (DR-098) ... Tapping the video surface pause-looped: it would unpause and bounce straight back to paused about a second later. Long-press unpaused fine, which is what pinned it to the tap path rather than the media pipeline. The gesture handler deferred the first tap's play/pause behind a 300ms timer so a second tap could cancel it and seek instead. But the timer callback cleared its own handle *before* invoking the toggle, and handleVideoClick used exactly that handle (`tapTimeout !== null`) to suppress the compatibility click Android's WebView synthesizes after a touch. So the guard was already open when the late click arrived, and it toggled a second time. Replace the deferral with immediate action — there are only first and second taps: 1st tap: toggle play/pause 2nd tap: seek, then toggle play/pause again The second toggle undoes the first, so a double tap seeks while leaving the play state exactly as it was: playing jumps and keeps playing, paused jumps and stays paused. No timer, no window race, no loop. Click suppression no longer depends on the timer: ignore detail === 0 and any click within 700ms of a touch tap, since Android can deliver the synthesized click late and with a real detail value. A swipe now undoes the touchstart toggle (latched on swipeGestureActive so it happens once, not per touchmove frame), keeping brightness swipes from changing the play state. UT-085..087 described the old deferred behaviour and are updated to the new contract. UT-091 is used for the DR-097 facade tests, since UT-089 and UT-090 were already claimed by extract-traces.test.ts.	2026-07-30 14:53:20 +02:00
dtourolle	75cd07a5c0	fix(player): decide transport in Rust for webview media (DR-097) ... Video on Android/Linux renders in a webview <video> element, and the frontend facade short-circuited play/pause/toggle straight into the adapter whenever one was registered. Html5PlayerAdapter.toggle() then decided play-vs-pause by reading el.paused off the DOM, so the Rust controller never saw the intent and could not serialise competing ones. el.paused flips transiently while an element buffers or settles a seek. Two intents ~150ms apart therefore read *different* values and performed *opposing* actions — one playing, one pausing — which self-sustained a play/pause loop that needed no further input. On device this showed up as a fully healthy element (readyState=4, networkState=1, not seeking, not buffering, not ended) pausing itself roughly once a second, so unpausing or skipping ahead bounced straight back to paused. The root cause was that Rust held NO state for webview-rendered media: report_html5_state only re-emitted its argument, despite the comment above it claiming the controller was the single source of truth. It had nothing to decide a toggle from. Now report_html5_state tracks the reported state, and play/pause/toggle consult it and drive the element by emitting a ControlCommand — the same "backend decides, adapter executes the primitive" split player_seek_video already uses. A stopped/idle report clears the tracking so MPV/ExoPlayer regain authority for music playback. Tests cover the loop signature directly (repeated toggles must alternate, never repeat or oppose) plus a guard that one intent yields exactly one ControlCommand — which matters on Windows, where the backend is itself webview-based and could otherwise be driven twice.	2026-07-30 13:54:41 +02:00
dtourolle	5b810f7fc3	build(android): add --device/--abi to build only the needed architecture ... An on-device test build compiled all four ABIs (arm64/arm/x86/x86_64), so three of the four Rust compiles were thrown away. That dominated the build time when iterating against a connected phone. --device resolves the attached device's ABI via adb and targets just that triple; --abi <target> selects one explicitly; ABI= works as an env var. Default behaviour is unchanged (all four), since a distributable universal APK genuinely needs them. bun run android:build:device bun run android:build:release:device	2026-07-30 13:16:52 +02:00
dtourolle	1ae213ff39	fix(player): stop AbortError storm from HLS stall recovery (DR-096) ... Html5PlayerAdapter.play() reported every interrupted play attempt as a player error. While an HLS stream stalls, hls.js' gap-controller nudges the element to recover, which cancels the pending play() promise and raises AbortError ("play() request was interrupted by a call to pause()"). That is transient — the element is still trying to play — but it hit host.onError roughly once a second for the whole stall, leaving the UI stuck reporting paused. Treat an interrupted play as a debug-level non-event, and memoise the in-flight attempt so the UI and recovery paths share one element.play() rather than stacking calls that abort each other. This is the loop amplifier, complementing DR-095 which removed the dead-segment stall that triggered it. Note: webviewAudioAdapter.play() has the same raw shape but is not implicated — audio playback does not go through hls.js — so it is left unchanged rather than widening this fix.	2026-07-30 12:55:49 +02:00
dtourolle	98a6bca645	fix(player): clamp seeks inside media to stop end-of-stream pause loop (DR-095) ... Seeking near the end of a transcoded video locked the player into a stall/pause loop: unpausing or skipping bounced straight back to paused. Both seek paths clamped the target to exactly `duration`. hls.js then requested the segment whose start time lies *past* the end of the media (a 6330.324s item asks for segment 1055, starting at 6336.33s). Jellyfin never produces that segment, the fetch times out, and the gap-controller stalls forever at the last buffered position — retrying ~1x/second and firing an endless stream of AbortErrors as play() lands mid-nudge. Clamp strictly inside the media instead, keeping one segment length (6s) of margin, floored at 0 so short media still seeks to the start. The seek-bar drag path needed this too: its range input `max` is the duration itself, so dragging fully right produced the same dead target. Also bumps the requirement-count fixture for the new DR-095 row.	2026-07-30 12:52:03 +02:00
dtourolle	f49e6e4648	fix(boundary): detect item-type arrays anywhere in src/ (DR-094) ... check:boundary passed on the very leak it was written for. The pattern was anchored to `includeItemTypes:` at the query site, so searchScope.ts assigning the same array to a named const and dereferencing it one indirection away was invisible — through every green CI run. The check now matches an array literal naming two or more Jellyfin item types anywhere in src/, catching a const, a Record value, a function return, and an inline query alike. Deliberate limits kept: two adjacent literals required (single-type presentation stays legal), string literals required (item.type === "Audio" is display logic), explicit type list (so ["High","Low"] produces no noise). Verified all five cases: reintroducing the original SCOPE_ITEM_TYPES fails; a new const ["Movie","Series"] fails; the same array in a .test.ts passes; itemType: "Movie" / item.type === / ["High","Low"] pass; a 5th allowlist entry fails on the new cap. Allowlist 1→3 entries, capped at 4 so the next exception forces a conversation rather than a one-line append: - GenericMediaListPage: grid styling over a self-declared itemType — presentation, changes only with a UI redesign. - DownloadedBrowse: borderline, leans domain (the container set grows when Jellyfin adds a container type). Allowlisted with a TODO for a backend MediaItem.isContainer flag. The header now names what the check still cannot see — run-time-built sets, types split across variables, switch/|| taxonomy — and CLAUDE.md states that a green check:boundary is not proof. That matters given this check passed on its own founding violation for months. Also: both gates wired into test-all.sh, which called `bun run test` without --run and would have hung in watch mode. Corrected the Dockerfile comment describing the Windows toolchain as mingw/GNU — it is MSVC via cargo-xwin (GNU cannot bundle NSIS from Linux).	2026-07-30 10:30:55 +02:00
dtourolle	0a3ee0791f	chore(scripts): remove three broken, orphaned traceability scripts ... All three shared one root cause: an unscoped `grep -r src-tauri/`, which walks ~40GB of target/ build artifacts. - check-req-coverage.sh: also read README.md, which has held zero requirement rows since they moved to docs/requirements.md. Reported "Total Requirements: 1", zeros in every category, then printed "All requirements have implementations!" — the opposite of a warning, from an empty result set. - check-test-coverage.sh: hung indefinitely, no output at all. - find-req-implementations.sh: same hang. None was referenced by CI, package.json, or the docs. They were salvageable — the greps just needed scoping — but they read an undocumented `@req:` / `@req-test:` tag convention parallel to `TRACES:` (146 and 76 occurrences, described in no doc; CLAUDE.md documents only TRACES). Repairing them would re-establish the second source of truth that let "1 requirement" and "211 requirements" coexist unnoticed. extract-traces.ts is now the single owner of coverage reporting. The existing @req:/@req-test: comments are left in place: harmless as prose, several encode useful test intent, and stripping 222 comments is a large diff with no functional gain. They are simply no longer read.	2026-07-30 10:30:20 +02:00
dtourolle	0da0a9f16c	fix(ci): derive traceability denominators from requirements.md (DR-093) ... The coverage gate divided traced counts by hardcoded literals (UR/39, IR/24, DR/48, JA/3, TOTAL_REQS=114) that had fallen out of date as requirements grew to 211. It reported 158% coverage — JA alone printed 800% — so the 50% threshold was mathematically unreachable and the job could not fail. Coverage could have collapsed to 30% and CI would still have printed a green tick. Real coverage is 86%. The number was fine; the gate was dead. extract-traces.ts now owns both sides of the fraction: - countDefinedRequirements() counts an ID only where it leads a markdown table row, ignoring the "Traces To" column and prose. IDs are deduplicated because requirements.md lists every UR twice (§1 definition + §3 matrix), which would otherwise report UR as 121/61. - computeCoverage() uses the intersection of traced and defined IDs, so a TRACES comment naming a deleted or typo'd requirement is reported as `orphaned` rather than inflating the ratio past 100%. UT/IT test identifiers are excluded as a separate taxonomy. - CI reads .coverage.percent and fails on <50% or >100%; a >100% reading is now a hard error rather than the condition that hid this bug. - New `bun run traces:coverage` runs the same computation locally. - scripts/ added to the scan roots — the coverage tool was invisible to the matrix it generates. Tests written first (15, over fixtures so they don't drift as requirements are added). vitest include widened to scripts/** so build tooling is covered by the normal suite. Verified empirically rather than by inspection: forcing the threshold to 99% fails; adding a requirement lowers coverage 86%→85%; a TRACES: DR-999 lands in `orphaned` without changing `covered`. traceability-ci.md documented the same stale numbers and would have let the broken arithmetic be reconstructed — replaced with a pointer to the live command.	2026-07-30 10:30:08 +02:00
dtourolle	742ad88a29	feat(build): cross-platform desktop packaging; bump to 0.1.0 ... Adds Docker-based packaging for Linux desktop (deb/rpm), Arch (.pkg.tar.zst via makepkg), and Windows. Windows cross-compiles from Linux via the official Tauri path — the x86_64-pc-windows-msvc target driven by cargo-xwin — and produces an NSIS installer (nsis via tauri.conf.json targets, since the CLI rejects --bundles nsis on a Linux host). Verified end to end: builds jellytau.exe + jellytau_x64-setup.exe. Unifies everything on one registry builder image (Dockerfile.builder): Android SDK/NDK, rpm/file, clang(+clang-cl)/lld/llvm/nsis, cargo-xwin and the msvc target. Packaging tools sit in a trailing layer so tool changes rebuild in ~1min instead of ~15. Desktop stages are thin FROM ${BUILDER_IMAGE} layers; Arch uses a separate archlinux image. CLAUDE.md: CI must install no system toolchains — everything lives in the image. Bumps version 0.0.18 -> 0.1.0 (Windows support + webview audio + equalizer). TRACES: UR-003, UR-005 | DR-004	2026-07-24 23:49:50 +02:00