265 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
dtourolleandClaude Opus 5	e4632bb2b2	fix(sync): queue a watch position the server could not be told about (DR-154) ... sync_queue and its drain (DR-131) were built, tested and running, but the stop-report path never fed them, so closing a video while the server was unreachable lost the resume point outright. HybridRepository::report_playback_stopped is a bare pass-through to the online repository ("Playback reporting goes directly to server"), and on failure the error surfaced to a frontend catch whose own comment read "Server error - could queue, but for now just log". Both producers that would have queued it -- PlaybackReporter::queue_for_sync in Rust and syncService.queuePlaybackProgress on the frontend -- have no callers on the playback path. user_data.pending_sync was dutifully set to 1, but nothing drains that flag for positions the way favourites do (DR-120). The command layer now enqueues a report_playback_stopped row whenever the push fails; the existing drain already parses and replays that operation. The pending row for an item is superseded in place rather than appended to: progress is reported every 10s, so a server that stays down would otherwise add a row per tick, all obsoleted by the newest -- the unbounded queue DR-131 exists to prevent. Only pending/failed rows are superseded, since reviving an abandoned row restores that same growing counter. Queueing is best-effort and never fails the command: the local position is already saved, so a failed queue write must not be reported as a lost position. Verified red->green in the jellytau-builder image: the four new tests failed to compile (enqueue_playback_stopped not found) before the fix. Full Rust suite passes (627 tests), cargo fmt clean, clippy adds no new warnings; frontend suite (933) and svelte-check also clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 19:18:11 +02:00
dtourolleandClaude Opus 5	2d50744320	fix(player): resume at saved position on the Android native path ... The native (ExoPlayer) video path never applied the resume position, so "resume from where you left off" always played from the start on Android. Two layers each assumed the other did the seek: - The only code acting on `initialPosition` was handleCanPlay, an HTML5 <video> event handler. The native path has no <video> element, so `canplay` never fires and that seek never ran. - NativePlayerAdapter.load() had an initialPosition branch, but it only recorded the number, claiming "the native backend performs the actual seek internally". It does not: PlayItemRequest carries no start position, and loadWithMetadata -> prepare() always starts ExoPlayer at 0. - VideoPlayer never called adapter.load() at all, so even that branch was unreachable. The frontend therefore believed it had resumed (the seek bar showed the resume point) while ExoPlayer played from the beginning. NativePlayerAdapter.load() now issues the backend seek, excluding live streams (no resume point; seeking knocks the HLS window off its live edge). VideoPlayer calls it on the native branch and marks the initial seek as performed so the existing $effect does not fire a duplicate. The HTML5 path is untouched: seeking before metadata is clamped to 0, which is exactly what handleCanPlay waits for. Verified red->green: the new test failed with "Number of calls: 0" before the fix. Full frontend suite passes (933 tests); svelte-check and check:boundary are clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 18:51:37 +02:00
dtourolleandClaude Opus 5	adc460f35d	fix(downloads): honor the selected bitrate (videoBitRate, capital R) ... Downloading at a specific quality silently returned the full-size original. The download URL builder spelled the transcode params `videoBitrate`/`audioBitrate`, but Jellyfin binds `videoBitRate`/ `audioBitRate` — with a capital R. Query-key binding is case-insensitive, so this is not a casing preference: the lowercase-r form is a different token that fails to bind. The server discards it without error and then stream-copies the source, so picking "480p" produced an original-quality file with no failure surfaced anywhere. `maxHeight`/`videoCodec` were unaffected (case-insensitive binding covers them), which is why the height cap applied while the bitrate cap vanished. Also set `allowVideoStreamCopy=false` on the transcode presets to force a real re-encode. Video stream-copy is gated by `allowVideoStreamCopy`, not `enableAutoStreamCopy` — the latter governs audio only. `original` is unchanged: it stays a deliberate direct static copy, now pinned by a test. The pre-existing unit tests asserted the broken lowercase-r spellings, so they passed against broken code; corrected. Verified red -> green by extracting the pre-fix and post-fix builder bodies into an isolated harness: 15 assertion failures before, 0 after. TRACES: UR-071 | DR-123 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 18:44:54 +02:00
dtourolleandClaude Opus 5	9d7cb085e9	fix(series): resume after the furthest-watched episode, not the first gap ... `pick_current_episode` rung 3 returned the first unwatched episode in series order. A viewer who skipped the pilot but is three seasons deep was sent back to S1E1: the gap was a deliberate skip, not the place they stopped. This read as flaky rather than consistently wrong because rung 3 only fires when the server's Next Up (rung 2) yields nothing, and `resolve_current_episode` swallows that call's errors with `.unwrap_or_default()`. `HybridRepository::get_next_up_episodes` delegates unconditionally to the online repo, so any unreachable-server moment silently degraded to the empty vec — same series, same watch state, different answer depending on one request's outcome. Rung 3 now scans the ordered list from the end with `rposition(is_played)` and returns the episode after the furthest-watched one, falling back to the previous first-unwatched behaviour when nothing is watched or the series is finished. Season crossing comes free from the already-flat series ordering, and `season_rank` keeps specials last so a watched special cannot mark a show finished. Tests written first and confirmed failing (S1E1 where S3E4 was expected), covering the skipped-pilot case, rolling into the next season past a skipped episode, and the watched-special case. All 17 existing tests still pass. Note: cargo test could not run locally (javascriptcoregtk-4.1 / webkit2gtk-4.1 absent on this host). The pure policy half plus its verbatim test module were extracted into a standalone crate to get real red/green; the full crate suite still needs a run on a complete toolchain. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 18:23:26 +02:00
dtourolleandClaude Opus 5	85bd227714	fix(home): uniform card heights in the Your Libraries row ... MediaCard derives its artwork aspect ratio from the item, so a music library rendered aspect-square (144px tall at w-36) next to video libraries at aspect-video (81px), leaving the home row ragged. Add an optional `aspect` prop that overrides the derived ratio, and pass aspect="video" from the home Libraries strip. Unset, behaviour is unchanged, so the /library overview grid and the media carousels keep their per-type ratios. Artwork already uses object-cover, so square music art crops rather than distorts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 18:13:27 +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> v0.5.0	2026-08-11 21:21:58 +02:00
dtourolle	8e081845d0	Merge pull request 'Feat/android native video' (#13) from feat/android-native-video into master ... Reviewed-on: #13	2026-08-11 19:03:45 +00: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
dtourolleandClaude Opus 5	c480276a97	docs(spec): native video confirmed working on device ... The spike's central question — can a SurfaceView be composited behind a transparent Tauri WebView on Android — is answered yes, verified on a physical device. No upstream issue blocked it and none demonstrated it; this appears to be the first working instance. Marks DR-148 done behind the flag and records what is confirmed versus what is still open: playback and positioning are verified, but the individual native controls (seek, audio-track, subtitle), the mini-player transition, and the MediaCodec hardware-decode claim are not yet each measured. The mini-player transition is called out as the known gap, since it is the one case where the fullscreen assumption behind "no rect plumbing needed" does not hold. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 20:57:58 +02:00
dtourolleandClaude Opus 5	ca490c34ec	docs(traceability): regenerate matrix for the native-video requirements ... DR-148/149/150 now resolve; coverage 86% (243/283), no orphans. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 20:57:58 +02:00
dtourolleandClaude Opus 5	e144e62b31	feat(player): render Android video natively behind a transparent webview (DR-150, DR-151, DR-152) ... Rust already reported `use_html5_element: false` on Android, but two frontend overrides threw that answer away, so ExoPlayer's video path had never actually run. Both are lifted behind an `experimentalNativeVideo` opt-in (default off). The flag is a suppressor, never a promoter: off forces HTML5 even where Rust says native, so an in-progress spike cannot ship as the default, but it can never select native where Rust reported HTML5 — Linux cannot composite behind WebKitGTK, and promoting there would be a black screen. Two blockers the spec did not anticipate, both in code assumed to be merely unreachable rather than broken: - `JellyTauPlayer.setActivity()` had zero callers, so `currentActivity` was always null and `autoAttachSurface()` bailed. The SurfaceView was created and wired to ExoPlayer but never added to the view hierarchy — video would have decoded to a surface that was never on screen, whatever the webview did. This also revives PiP on the video path, which gated on the same flag. - `createAdapter()` was not the real gate; it is never called in production. The actual override was in VideoPlayer.svelte, which forced HTML5 and stopped the native backend `player_play_item` had just started. Both sites now route through `createAdapter()`. Compositing needs two independent opaque layers cleared, not one. Clearing only the page leaves the WebView widget opaque — audio over a black picture, exactly the symptom the old INTERIM comment described. `videoSurface.ts` toggles both: the widget background and window drawable from Kotlin, the page backgrounds via a `data-native-video` attribute keyed by app.css. Transparency lives in `tauri.android.conf.json` so Linux keeps an opaque window, and is scoped to the playback session so the launcher never shows through the rest of the app. Phase 3's rect plumbing turned out to be unnecessary: video is fullscreen on the player route, and `fitSurfaceToScreen()` already letterboxes and re-fits on rotation. The mini-player transition remains unverified on device. Also removes the `navigator.userAgent` sniffing in webviewAudio.ts, which was a second copy of the Rust cfg gate free to drift from it. `player_get_capabilities` now reports `usesWebviewAudio` and `supportsNativeVideo` from those same gates. Tests: adapter selection covers the full matrix, including the regression guard that the flag off beats Rust. Written first and confirmed failing (2 of 7) before the fix. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 20:57:58 +02:00
dtourolle	07d10dfed7	docs(traceability): land the DR-149 requirement rows and settle a UT collision ... The DR-149 row lost an index race with a parallel session's edit of the same file, so the previous commit carried the count assertion (DR 144, total 282) without the requirement it counts — a clean checkout of that commit failed `bun run test` against its own requirements.md. The parallel session also reached UT-143 and UT-147 for subtitle work, which collided with the UT-143 used for the client-side transcode tests. Those move to UT-148, in the table and in the device_profile TRACES comments, so no two requirements share an ID. v0.4.8	2026-08-11 20:11:22 +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	6a712c46cb	fix(player): send subtitle tracks to ExoPlayer on Android (UR-020) ... Selecting a subtitle on Android did nothing. The Kotlin side has been complete for a long time — JellyTauPlayer.load() parses a subtitles JSON array into MediaItem.SubtitleConfigurations and setSubtitleTrack() drives a TrackSelectionOverride — but nothing ever reached it. VideoPlayer built the list and then threw it away: it resolved every subtitle stream's URL into a subtitleTracks array and the commands.playerPlayItem({...}) call two lines below passed only streamUrl, title, id, videoCodec and needsTranscoding. PlayItemRequest had no subtitle field to put them in, so create_media_item hardcoded subtitles: vec![], android/mod.rs serialized "[]" across JNI, and every MediaItem reached ExoPlayer with zero SubtitleConfigurations. A later set_subtitle_track then found no text track groups and logged "Invalid subtitle track index". PlayItemRequest now carries the tracks (defaulted, so the background-audio handoff and next-episode callers are unchanged) and create_media_item threads them onto the MediaItem. Serialization: SubtitleTrack is reused verbatim rather than given an IPC-specific twin, and deliberately keeps snake_case. The same struct feeds two consumers that both spell mime_type — the JNI JSON that JellyTauPlayer.load() reads with optString("mime_type"), and the generated binding the frontend types against. camelCasing it would not fail the build or the IPC; Kotlin would silently fall back to its default MIME type for every track. UT-146 asserts the exact serialized keys so a future rename_all cannot pass unnoticed. The index mapping was NOT already correct. setSubtitleTrack(n) indexes ExoPlayer's filtered text track groups, i.e. the position of the sideloaded configuration — but the menu passed its own {#each} row number, which counts every subtitle *stream*, including ones whose URL failed to resolve and were therefore never sideloaded. One failed URL and every track below it selected the wrong subtitle. The position is now looked up in the exact array that was sent (nativeSubtitleArrayIndex), and a stream that was never sent maps to "off" rather than to a guessed position. The resolution loop also reuses resolveSubtitleTracks() from the Linux fix instead of duplicating it, which fans the URL requests out in parallel rather than awaiting them one per stream before playback can start. The awaits are safe where they sit: the native-mode pitfall is about Svelte lifecycle calls after an await, and nothing is registered here — the background-audio subscriptions above still run synchronously. No Kotlin change was needed. Tests (UT-145, UT-146, UT-147) were written first and failed: PlayItemRequest had no subtitles field to compile against, nativeSubtitleTracks and nativeSubtitleArrayIndex did not exist, and the playerPlayItem call carried no subtitles key. TRACES: UR-020 | IR-016, JA-008 | UT-145, UT-146, UT-147	2026-08-11 20:03:19 +02:00
dtourolle	211792947d	fix(player): render subtitle tracks on the Linux HTML5 path (UR-020) ... Selecting a subtitle on Linux did nothing. VideoPlayer rendered no <track> children at all — the block was commented out as "temporarily disabled to debug playback issues" (it has been that way since the POC) — so Html5PlayerAdapter.selectSubtitle() walked an empty textTracks list and the menu, which is built from media.mediaStreams, was purely decorative. The reason it had to be disabled is still visible in the dead markup: getSubtitleUrl() is async, so src={getSubtitleUrl(track.index)} bound a Promise to the attribute and every track pointed at "[object Promise]" — an unloadable resource hanging off the media element. Subtitle URLs are now resolved off the render path into component state (subtitleTracks.ts), and only streams whose URL actually resolved are rendered; a per-track failure drops that track instead of emitting a dead src. data-stream-index is kept, since that is what the adapter matches on. Subtitles stay OFF unless the user asks for them: the server's isDefault flag is shown in the menu but is never promoted to a selection, and the `default` attribute is deliberately not emitted. A <track default> auto-shows, so the menu would open on "Off" while subtitles were burned over the picture, and every user who never wanted subtitles would suddenly get them. That matches the existing initial state (selectedSubtitleIndex = null). Selection and rendered tracks are reconciled whenever the list changes: a selection that no longer resolves collapses to "Off", and a surviving one is re-applied after the new <track> elements exist. "Off" disables every text track, as before. Cross-origin text-track fetches use the media element's CORS setting, so the element opts in with crossorigin="anonymous" — but only for an http(s) stream, never for a local/offline file:/asset: source, where forcing CORS onto the video fetch could break playback. It is keyed on the subtitle stream count, known at first render, so the attribute cannot flip under an in-flight media load. Android/native is untouched: the ExoPlayer branch still goes through player_set_subtitle_track. Tests (UT-143, UT-144) were written first and failed against the old markup: the commented-out block, the Promise bound to src, and the default attribute. TRACES: UR-020 | DR-023 | UT-143, UT-144	2026-08-11 19:25:39 +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. v0.4.6	2026-08-09 16:38:07 +02:00
dtourolle	7b531a40be	fix(player): pick a decodable track in the no-audio fallback (DR-146) ... When ExoPlayer selected no audio track, the recovery forced group 0 / track 0 unconditionally. But the most likely reason nothing was selected is that this very track cannot be decoded on this device, so the override reinstated the silence it was meant to fix. Scan the groups for the first isTrackSupported track and override to that. Also clear setTrackTypeDisabled(TRACK_TYPE_AUDIO), since audio may equally have been off at the type level, which an override alone does not undo. When no group holds a supported track, log it as an error — the server was expected to transcode — instead of leaving a silent video with no explanation in the log. Verified by compiling :app:compileArm64DebugKotlin. Not unit-tested: this tree has no Kotlin test source set, as noted in the previous commit.	2026-08-09 15:07:18 +02:00
dtourolle	19bc265a8d	fix(player): do not start a video before audio focus is granted (DR-145) ... Video manages audio focus by hand (handleAudioFocus=false, since ExoPlayer's automatic handling is reserved for the audio path), and all three outcomes of the request were treated as success. AUDIOFOCUS_ REQUEST_DELAYED — which setAcceptsDelayedFocusGain(true) explicitly invites, and which means the system is withholding our audio until it calls back — and an outright REQUEST_FAILED were logged and then followed by playWhenReady = true. The picture rolled with no sound, which to the user is indistinguishable from a broken stream. Hold playback when focus is not granted and start it from the AUDIOFOCUS_GAIN callback. An explicit play() re-requests focus instead of resuming into a stream the system is still muting, guarded by a held-focus flag so repeated plays do not leak focus requests. LOSS clears the pending flag so an unrelated later GAIN cannot start playback the user never asked for. Verified by compiling :app:compileArm64DebugKotlin. Not unit-tested: this tree has no Kotlin test source set (the Gradle project lives in the generated, gitignored gen/ tree), so the logic cannot be exercised off device without restructuring the Android build.	2026-08-09 15:06:49 +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	a53042fe80	fix(playback): bound the device profile by the audio route's channels (DR-141) ... MediaCodecList answers "can this device decode 5.1", which is not the question that decides whether the user hears anything: a phone decodes an AC-3 5.1 track happily and still has two channels to play it out of. The DeviceProfile carried no MaxAudioChannels, so Jellyfin was free to direct-play the multichannel track to a two-channel sink — silence or dialogue folded into surround channels that go nowhere, depending on the device. Report media3 AudioCapabilities.maxChannelCount for the current route over JNI alongside the codec lists, and bound the direct-play and transcoding profiles (and the HLS URL's TranscodingMaxAudioChannels, previously hardcoded to 2) by it. No codec is ever removed, so a device with genuine surround output keeps direct-playing it. A missing or zero reading means "route not yet established", not "no audio", and falls back to stereo.	2026-08-09 15:01:57 +02:00
dtourolle	db520c6551	fix(playback): stop pinning the video stream as the audio track (DR-140) ... Jellyfin's MediaStream.Index is global across every stream in a media source, so index 0 is the video stream on virtually all files. We sent AudioStreamIndex=0 as "the first audio track" on the HLS transcode URL, the background audio-only handoff URL, the direct-play fallback URL and the PlaybackInfo negotiation body — asking the server to use the video stream as audio. Servers that honour it produce a picture with no sound; only those that silently correct the index hid the bug, which is why it surfaced as "some videos have no audio". Omit the parameter unless a track was actually chosen, so the server resolves the source's DefaultAudioStreamIndex. An explicit selection from player_switch_audio_track still passes through unchanged. Dropped outright from the static=true direct-play URL, which serves the original file untouched.	2026-08-09 14:47:03 +02:00
dtourolle	1ef6180776	chore(release): bump to 0.4.1 v0.4.1	2026-08-05 12:31:16 +02:00
dtourolle	878ac5fa59	fix(player): make lockscreen transport reach background audio (DR-097) ... Pausing from the lockscreen did nothing while a video's audio played in the background. The handoff starts native ExoPlayer audio and only then tears the WebView <video> down, and that teardown fires a DOM `pause` the frontend reports like any other — leaving html5_playing = Some(false). Transport therefore stayed aimed at the element: the lockscreen pause emitted a ControlCommand into a <video> that no longer existed while the native player carried on. The controller now tracks a background-audio handoff explicitly. Entering one hands transport authority to the native backend and drops the dying element's state/position/media-loaded reports, which also stop flipping the UI to paused and dragging the position backwards. Exiting restores the element as the player. A lockscreen pause also has to survive the return to the foreground: the video used to resume from a snapshot taken at handoff time, undoing the pause on the way back in. shouldResumeOnForeground() lets an explicit `paused` from the player override that snapshot. TRACES: UR-040, UR-005 | DR-052, DR-097	2026-08-05 12:26:25 +02:00
dtourolle	6aaa80ff92	chore(release): bump to 0.4.0 v0.4.0	2026-08-04 20:22:01 +02:00
dtourolle	f7bcfe521d	fix(favorites): save server favourites through to the cache (DR-115) ... The hybrid favourites read went straight to the online repository on a cache miss and dropped the result on the floor. Every other read path persists what it fetches, so this one made the favourites page re-query the server on every visit — and left the offline mirror (DR-114) empty on a fresh install, since this is the path that fills it. It now goes through get_favorites_server_only, which saves through on the way back. The command had a matching hole: with nothing cached it returned the empty result, painting "Nothing favourited yet" at a viewer whose favourites were simply marked on another client. It now asks the repository for a real answer instead of an empty state it would correct a round trip later. TRACES: UR-067 | DR-115	2026-08-04 20:20:36 +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	32f8de5c91	fix(player): survive a flaky stream, and don't read 0:00 at EOF ... Two MPV-side fixes for the same failure story — a wifi blip during playback. The demuxer gave up the moment a read failed and MPV raised EndFile(ERROR), so a momentary outage killed the track outright. Enabling ffmpeg's reconnect options handles the common case entirely below our level, so most outages never reach the recovery path at all. Set non-fatally: their availability varies with the libmpv/ffmpeg build, and losing resilience is not a reason to refuse to play anything. Separately, `time-pos` and `duration` are live properties of the *loaded* file: at EOF MPV unloads it and both stop resolving. Reading them straight through returned 0.0/unknown at exactly the moment end-of-file handling needed to know where playback had reached, so the player appeared to rewind to 0:00 as a track ended. `ObservedTime` records the last reading seen while media was loaded and the accessors fall back to it.	2026-08-04 19:39:14 +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 v0.3.0	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	a26a853f01	fix(player): advance background audio-only episodes in the backend (UR-040) ... An episode played audio-only while the app was backgrounded stalled at the episode boundary instead of advancing, and ExoPlayer parked in STATE_ENDED — where any later play intent (lockscreen, headset, Bluetooth reconnect) replays the ended item, surfacing as the episode randomly restarting. End-of-playback is dispatched from two places and they disagreed. The Android JNI callback carried the background-audio branch but can never reach it: load_and_play sets EndReason::NewTrackLoaded at every load and nothing clears it, so the first real end consumes it and the decision is always Stop. The call that actually decides is the frontend's echo of the resulting PlaybackEnded into player_on_playback_ended — and that path had no background-audio case at all, so it started a countdown whose advance is a webview goto() that cannot start audio while backgrounded. Both dispatchers now share PlayerController::auto_advance_to_next_episode, so they cannot drift apart again. The handoff base offset moves from the BackgroundAudioOffset Tauri state onto the controller, and the advance clears it: the next episode's stream is built without StartTimeTicks, so its timeline is already absolute and a stale base made player_exit_background_audio return old_base + position_in_new_episode. Unreachable until the advance actually worked. Tests (red before the fix): - test_auto_advance_background_audio_episode_advances_in_backend - test_auto_advance_foreground_video_episode_uses_countdown - test_advance_to_next_episode_audio_only_clears_handoff_base Bump to 0.2.9. v0.2.9	2026-08-02 18:10:18 +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. v0.2.8	2026-08-01 10:41:23 +02:00
dtourolle	e381d626c1	docs(requirements): UR-061/DR-092 no longer describe the removed deferral ... Both still described the 300ms deferred-tap design that DR-098 replaced with immediate action, so the generated release notes advertised behaviour the code no longer has. v0.2.7	2026-07-30 16:13:29 +02:00
dtourolle	b12e99b7e1	fix(player): keep double-tap seek working over the play overlay (DR-098) ... The control-surface guard added in the previous commit killed double-tap-to-seek. The first tap pauses, which renders the full-screen <button> play overlay over the video, so the SECOND tap lands on a button — and the guard discarded it as "a tap on a control". Mark that overlay `data-player-surface`: visually it IS the video, so it must keep taking tap gestures despite being a <button>. The marker wins over the interactive-tag check in isControlSurfaceTouch. Adds VideoPlayer.tapSurface.test.ts, which renders the REAL component and dispatches real touch/click events at whatever element is genuinely on top. This is the gap that let four bugs ship in a row: the pure-unit tests over registerTap/isControlSurfaceTouch/isSynthesizedTouchClick all passed throughout, because each helper behaved exactly as specified — every bug was in the composition, i.e. which element actually receives a tap after Svelte re-renders. Modelling that DOM by hand in a test would just re-encode the same wrong assumption, so these render it instead. The new double-tap test was verified to fail with the fix reverted and pass with it applied, in both directions.	2026-07-30 15:44:38 +02:00
dtourolle	dc8b732465	fix(player): controls bar taps are not player gestures (DR-098) ... The bottom play/pause button did nothing. The gesture listener lives on the outer container and touch events bubble, so tapping the button ran handleTouchStart (toggle #1) and then the button's own onclick (toggle #2). The two cancelled out, leaving the control apparently dead. Ignore container-level gestures for touches that land on an interactive control: buttons, links, inputs (the seek bar), or anything inside the controls bar, now marked `data-player-controls`. The rule itself is a pure function over the ancestor chain (isControlSurfaceTouch), so it is unit tested without a DOM. Same root shape as the play-overlay bug in the previous commit: a second click target over the video that the gesture layer did not account for.	2026-07-30 15:27:01 +02:00
dtourolle	b98a530f48	fix(player): guard the play overlay against the synthesized touch click ... After the DR-098 tap rewrite, pausing became impossible while unpausing always worked — an asymmetry that pointed straight at the overlay. Pausing renders a full-screen play-overlay button over the video. The compatibility click Android synthesizes from the tap arrives ~30-130ms later, by which time that button exists, so the click lands on the OVERLAY rather than the <video>. Its onclick called togglePlayPause with no guard at all, resuming immediately. Unpausing was unaffected because it removes the overlay, leaving nothing to intercept the click. The suppression rule was only wired into the video element's handler. Extract it as isSynthesizedTouchClick() in tapGestures.ts (unit-tested) and use it from every click target layered over the video, the overlay included. Verified: 724 frontend tests pass, svelte-check clean. Bumped to 0.2.5 so the APK installs over 2004.	2026-07-30 15:10:59 +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	79e10d7485	chore(release): bump to 0.2.3 ... Android versionCode derives from this (0.2.3 -> 2003); required for the APK to install over the 2002 build already on the device.	2026-07-30 13:56:04 +02:00
dtourolle	a2dbde5492	debug(player): log pause reason and flatten the debug tick ... An unexplained pause/resume loop was invisible over adb: handlePause logged nothing at all, so only the "playing" half of each cycle showed up, and the 1s debug tick logged an object — which the Android WebView console bridge renders as "[object Object]", discarding every field. Log the element state on pause (readyState, networkState, seeking, ended, plus the component's own isSeeking/isBuffering/handoff flags) and emit the debug tick as a flat string. This is what identified DR-097: the element was fully buffered and healthy at every pause, ruling out a stall and pointing at a competing controller instead.	2026-07-30 13:55:06 +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	64d07b8940	chore(release): bump to 0.2.2 ... Android versionCode is derived from this (0.2.2 -> 2002), so the bump is required for the APK to install over the 2001 build already on device.	2026-07-30 13:17:29 +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	984e594006	chore(release): bump to 0.2.1 v0.2.1	2026-07-30 10:39:07 +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	105cc082ea	fix(search): move scope→item-type taxonomy into Rust (UR-049, DR-063) ... Stage 1 of scoped-search-boundary-implementation.md — the query side. scoped-search-boundary.md diagnosed this leak, specified the fix in detail, and became the justification for the boundary rule in CLAUDE.md, the check:boundary tripwire, and the spec-review checklist. The fix was never built: SCOPE_ITEM_TYPES was still live in searchScope.ts, called by library.ts, and no SearchScope existed anywhere in src-tauri/. The rule's own founding violation was still shipping. Rust now owns the taxonomy: pub enum SearchScope { All, Music, Movies, Tv } impl SearchScope { pub fn item_types(self) -> Option<Vec<String>> } - SearchOptions gains `scope`, resolved by resolve_scope(). Scope wins over include_item_types, which stays for the non-search get_items callers that legitimately request one concrete type. - repository_search resolves the scope ONCE, before the cache/server paths diverge, so online and offline filter identically — the failure mode most likely to go unnoticed. - All expands to None (no filter), not the union of the other scopes: an explicit includeItemTypes list would silently drop People, folders, and any type nobody enumerated. - searchScope.ts re-exports SearchScope from generated bindings instead of a hand-written union, and no longer names an item type for search. - library.ts sends { scope }. 8 Rust tests written first, confirmed failing on "use of undeclared type SearchScope" before the implementation existed. The frontend tests that asserted includeItemTypes contents were rewritten to assert the opaque scope is sent and includeItemTypes is absent — keeping the old assertions would require the frontend to know the taxonomy again, defeating the fix. The expansion is now asserted in Rust. Verified the spec's headline criterion by hashing every src/ file, adding "AudioBook" to the Music scope in Rust, and re-hashing: zero frontend files change. That criterion failed before this commit. Stage 2 (result-side grouping: GROUP_ITEM_TYPES, GroupedSearchResult on both search payloads) remains open.	2026-07-30 10:30:38 +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