61 Commits

Include renames

Author	SHA1	Message	Date
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	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	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
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.	2026-08-11 20:11:22 +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.	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	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	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	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.	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.	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.	2026-07-30 16:13:29 +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	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	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	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	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	75bae2556c	docs(specs): design-principles audit — five remediation specs ... Audit of the principles in CLAUDE.md and docs/architecture/ against the actual code. Principles with a working automated check (poison-tolerant locking, Android source sync, one-directional playback state, graceful backend init, reachability-from-traffic) all held up. The two that drifted are exactly the two whose checks were broken or too narrow: - traceability-gate-repair: CI divided by hardcoded denominators (UR/39, IR/24, DR/48, JA/3, total 114) while requirements.md had grown to 211, reporting 158% coverage — the 50% threshold was unreachable and the job could not fail. - req-coverage-script-removal: check-req-coverage.sh reports "1 requirement" and prints "all requirements have implementations". - scoped-search-boundary-implementation: the founding boundary incident was specced but never built; the leak is still live. - boundary-tripwire-hardening: check:boundary passes on that same leak — the pattern is anchored to the query site, so a named const evades it. - player-facade-enforcement: 52 direct commands.player* call sites outside the facade, and no automated check at all. Each spec follows SPEC-TEMPLATE.md with a filled-in Layer assignment table and is checked against SPEC-REVIEW-CHECKLIST.md.	2026-07-30 10:29:54 +02:00
dtourolle	48f63dd763	docs(spec): build provenance — git describe + build profile ... A running JellyTau currently reports no version anywhere: not in the UI, not in the logs. When a user reports "the equalizer does nothing on my device" there is no way to tell whether they are on the v0.2.0 tag, master, or a three-week-old local debug build — a live gap given v0.2.0's Android audio settings are not yet device-verified. Specifies a build.rs-emitted `git describe --tags --always --dirty`, a typed BuildKind (Release/Untagged/Development/Unknown) classified in Rust rather than pattern-matched in the UI, a get_build_info command, startup logging, and a Settings > About block with copy-to-clipboard for bug reports. Explicitly does NOT derive the release version from git: Cargo needs a literal semver at manifest-parse time, so sourcing it from a tag would trade a reviewable bump for a build-time dependency that fails in CI's shallow Docker clones. The release version stays authored; only the provenance is derived — they answer different questions. Two constraints found while writing this: - Only publish-docs.yml sets fetch-depth: 0. build-release.yml has five checkouts and build-and-test.yml two, all of which would stamp "unknown" as-is. Flagged as an acceptance criterion. - tauri.conf.json's version field can be dropped to fall back to Cargo (three hand-bumped files becomes two), but gen/android/app/build.gradle.kts reads versionName/versionCode from generated Tauri properties, so that must be verified before adopting rather than assumed.	2026-07-28 23:19:34 +02:00
dtourolle	cb79a376b3	feat(android): implement audio settings (EQ, normalization, gapless) ... ExoPlayerBackend was the only backend not overriding the PlayerBackend trait's set_audio_settings/audio_settings defaults, so the Settings > Audio controls rendered on Android and silently did nothing — the default returns Ok(()) while applying nothing, so the failure was invisible. Rust owns what the values are (canonical 10-band ISO layout, preset curves, normalization presets); Kotlin owns when the AudioEffect objects exist, since that needs the live audio session id. - settings.rs: audio_settings_jni_payload() sanitises (crossfade clamped, band vector normalised) before serialising, so a malformed vector cannot reach the Kotlin parser. JSON rather than a wide JNI signature, matching how load() already passes subtitles — adding a field will not change the signature. - ExoPlayerBackend: set_audio_settings/audio_settings over JNI; ExoPlayerState gains the first command-side field (settings are pushed out, never reported). - JellyTauPlayer.kt: Equalizer, LoudnessEnhancer, and gapless via pauseAtEndOfMediaItems. Three details that are easy to get wrong: - Effects re-attach on onAudioSessionIdChanged. ExoPlayer rebuilds its audio sink on a format change, which invalidates effects bound to the old session; without this the EQ silently stops applying mid-queue. - All effect work is posted to mainHandler rather than run inline. AudioEffect construction from a player callback can re-enter the player and deadlock — the same shape as the AutoplayDecision lock-scrutinee bug. - Device equalizers expose a device-dependent band count (commonly 5) at fixed centres, so the canonical 10 bands are resampled by nearest centre frequency. resampleBands() is a pure @JvmStatic function so that mapping is testable without a device. Normalization is approximate, not parity: LoudnessEnhancer is a gain stage, not a true EBU R128 normalizer like MPV's dynaudnorm. Recorded as such rather than claimed as equivalent. Crossfade is deliberately excluded — unimplemented on every platform and blocked on mpv, so building it on Android alone would invert the parity gap. Tests written first and observed failing (cannot find function audio_settings_jni_payload) before the implementation: the payload contract is pinned by tests because a serde rename would otherwise silently break the Kotlin parser. Not yet verified on a physical device — AudioEffect availability and band layouts are device-specific. Requirements matrix marks these rows accordingly, and flipping the trait default to Err(not_implemented()) is deferred until that verification lands.	2026-07-28 23:03:31 +02:00
dtourolle	b11188e9dd	docs(player): backend unification findings + correct false parity claims ... Investigation into unifying the playback backends (Linux/MPV, Android/ExoPlayer, Windows/webview) onto one engine with hardware acceleration. Conclusion: video cannot be unified onto a native engine; audio can. The blocker is not mpv-specific. WebKitGTK, WebView2 and Android WebView each draw into their own compositor surface, so a native video surface sits either entirely above or entirely below the webview and cannot interleave with HTML. GStreamer and libVLC fail identically. mpv would additionally regress streaming: it has no adaptive bitrate, while the current hls.js path does. Six specs added: - playback-backend-unification: the analysis and decision, with evidence - android-audio-settings-parity: set_audio_settings on ExoPlayerBackend - android-native-video-spike: timeboxed test of SurfaceView compositing - windows-native-audio-backend: replace the webview <audio> shim with libmpv - libmpv2-migration: dead libmpv git pin -> libmpv2, plus a LICENSE file - playback-docs-corrections: the requirement-status fixes applied here Corrections to requirements.md, all verified against source: - UR-031/DR-034 claimed crossfade was "Done (Linux only)". It is implemented nowhere (mpv_backend.rs has a bare TODO) and is architecturally blocked on mpv, whose single-stream audio chain cannot feed acrossfade's two inputs. - Parity matrix listed crossfade as a Linux/Android gap; it is neither. - The matrix omitted the equalizer, which has the same Linux-only shape. - The suggested ConcatenatingMediaSource is deprecated in current Media3. nativeAdapter.ts cited tauri#10152 as an upstream blocker for native Android video. That issue is a stale feature request, dead since 2024-07-01; the capability shipped in tauri 27d01834 (2024-09-02), and the related black-screen bug was fixed in wry 0.39.4 (we ship 0.55.x). What is genuinely unproven is SurfaceView-behind-WebView compositing, which the spike now tracks.	2026-07-28 23:03:17 +02:00
dtourolle	37ffabee06	chore(release): bump to 0.1.5; regenerate traceability matrix ... Registers UR-061/DR-092 (tap gestures) and UT-062 (background-audio bridge reporting), and regenerates the matrix — 313 TRACES across 299 files.	2026-07-28 01:33:20 +02:00
dtourolle	d1c01a6bc3	feat(player): defer single tap so a double tap doesn't also toggle pause ... A tap cannot be classified when it lands — it may still turn out to be the first half of a double tap. Play/pause is therefore deferred until the 300ms double-tap window closes, and cancelled outright if a second tap arrives, so a double tap seeks without also toggling pause. Forward skip moves from 10s to 30s (back stays 10s), for both double tap and the keyboard arrows. The timing rules live in tapGestures.ts so they are unit-testable without mounting the player. Rapid double taps now chain off a still-in-flight seek target instead of all resolving against the same not-yet-updated position. TRACES: UR-005, UR-061 | DR-092 | UT-085, UT-086, UT-087, UT-088	2026-07-28 01:33:04 +02:00
dtourolle	b7a7037194	docs: add UR-060 search relevance requirement; regenerate matrix ... Records the search relevance and grouping behaviour as UR-060, with DR-090 (Rust relevance ranking) and DR-091 (Shows/Episodes split, People group, stored-order migration). DR-066 now points at DR-091 for the current group set instead of restating a default order that has since changed.	2026-07-25 15:13:52 +02:00
dtourolle	d01c1216b8	docs: red-green rule for bug fixes; regenerate traceability matrix ... CLAUDE.md now states the failing-test-first rule explicitly: write a test that reproduces the bug and watch it fail before applying the fix, and extract buried logic into a plain .ts module so it can be unit-tested. A test written against already-fixed code can pass for the wrong reason.	2026-07-25 09:21:22 +02:00
dtourolle	eb76c96e94	feat(player): skipping an episode marks it watched, not paused ... Skipping to the next episode left a mid-episode resume point behind, so the skipped episode reappeared in Continue Watching with a partial progress bar. Skipping means "done with this one", not "stopped here". - reportSkippedEpisode marks the outgoing episode played instead of reporting a stop position, and arms a one-shot suppression consumed by the player's stop handler, so VideoPlayer's post-navigation unmount stop report can't overwrite the 100% progress with the partial one. - Continue Watching drops resume entries superseded by Next Up: an in-progress episode whose series has a next-up entry strictly later in series order (season, then episode) is hidden from the Home and TV rows. Movies, series without a next-up entry, and items with unknown or mixed ordering are always kept. Adds UR-059, DR-088, DR-089. TRACES: UR-059 | DR-088, DR-089	2026-07-25 09:20:56 +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
dtourolle	c543f90ad3	feat(audio): graphic equalizer with presets and custom bands ... Adds a 10-band graphic equalizer to AudioSettings (enabled flag + per-band dB gains, normalised to 10 entries and clamped to range). Presets return gain curves; the settings page gains EQ UI. libmpv applies the filter on Linux (Android parity pending). Old persisted settings without EQ fields load as disabled + flat. Also includes the requirements/traceability/ux-flows doc updates for this feature and the home long-press routing (UR-058/DR-087). TRACES: UR-027 | IR-020, DR-030 | UT-079, UT-080, UT-081, UT-082	2026-07-24 23:49:13 +02:00
dtourolle	e2c9d68311	docs(downloads): mark UR-055/056 Done; fix colliding UT ids ... The browsable Downloaded library + Transfers split + on-disk usage (f25deba, plus today's grouping/perf fixes) fully implement UR-055 and UR-056, but the requirements doc still listed them and DR-081..085 as Planned. Flip to Done. Also fix UT-id collisions: the downloaded-browse and formatBytes tests reused UT-046..050 (already assigned to smart-cache/playlist tests in the matrix). Reassign to UT-071..078 and register them in §4, including the new music/TV container-rollup and orphan-leaf regression tests.	2026-07-24 22:22:43 +02:00
dtourolle	6391720d23	docs(offline): mark UR-052 offline-listing feature and its tests Done ... The DR-079/DR-080 root-cause fixes for issue #10 landed in 8f4f651; the requirements doc still listed UR-052 (and DR-078/079/080, UT-068/069/070, IT-016/017) as Broken/Partial/Pending. Flip them to Done and regenerate the traceability matrix. Existing backend tests already cover the IT-016/017 end-to-end scenarios (annotated with their IDs in the code commits).	2026-07-24 21:41:57 +02:00
dtourolle	9b1c9b3c91	feat(settings): rework settings page; remove unused SkeletonLoader/StorageManagement ... Settings page refactor plus supporting docs (requirements, ux-flows, traceability) and the frontend-domain-model spec with implementation-status banner. Removes SkeletonLoader and StorageManagement components (no remaining references).	2026-07-23 22:18:37 +02:00
dtourolle	8b028b6b60	docs: specs, requirements, ux-flows and traceability for new features ... Add specs for the account menu, downloads-as-offline-library, offline downloaded-only filter, and scoped search (+ boundary revision). Add the new UR/DR entries to requirements.md, update ux-flows, and regenerate the traceability matrix. TRACES: UR-049, UR-050, UR-052, UR-053, UR-054, UR-055, UR-056	2026-07-23 20:04:35 +02:00
dtourolle	3fbf6afdbc	Background-audio handoff for video + repository/player refactor ... Hand video playback off to a native audio-only stream when the app is backgrounded or locked, with no on-device video decode (UR-040). Adds player_enter/exit_background_audio commands, an audio-only stream URL for video items across the repository layer, and the frontend handoff state machine wired into VideoPlayer. Includes accompanying repository/offline/player refactoring and regenerates the traceability matrix.	2026-07-22 21:52:07 +02:00