75 Commits

Include renames

Author	SHA1	Message	Date
dtourolle	68ca1d585d	chore: regenerate bindings and the traceability matrix ... bindings.ts picks up the library-exclusion commands and types from tauri-specta. The matrix regenerates because validation.ts and its test are gone — the doc link checker caught the stale references, which is the first time that gate has paid for itself on a generated artifact rather than a hand-written link. Also drops exclusions::is_excluded: a wrapper over is_excluded_by that only a test called, while the trait impls hoist the snapshot themselves. The test now calls the same path production does.	2026-08-20 20:14:15 +02:00
dtourolle	0815445aa7	feat(library): exclude chosen folders from music browsing ... Replaces a hardcoded filter that dropped anything named "Podcasts" from music results — one user's library layout compiled into the shipped product, keyed on an English literal, applied only at the six call sites someone had remembered. Exclusion is now a user setting stored in Rust and applied at the repository layer's convergence points, so scope is decided once and is the same on every screen. It matches on folder id rather than name: a title is not what an item is, which is why an album legitimately called "Podcasts" used to vanish. Deliberately not filtered: get_item (an id asked for by name was navigated to on purpose, and refusing it would break playback of anything inside a hidden folder), get_downloaded_items (hiding a download would leave the user unable to delete a file whose disk usage they can still see), and the offline cache (an exclusion is a view preference and must be reversible without a re-crawl). Also removes src/lib/utils/validation.ts — six exported validators with no caller outside their own test file, which made the module read as covered input validation while guarding nothing. TRACES: UR-076 | DR-209 | UT-203	2026-08-20 20:09:57 +02:00
dtourolle	048c99ebcc	fix(downloads): allow the deliberate join_absolute_paths lint in a test ... The assertion documents that PathBuf::join discards its base when handed an absolute path — which is why confinement has to happen after the join, not instead of it. clippy::join_absolute_paths flags that shape, correctly for production code, so the lint is allowed here rather than the test weakened. Worth recording: this lint would not have caught the original defect. The real join sites pass a variable, and it only fires on a literal.	2026-08-20 20:09:19 +02:00
dtourolle	f83c7ed1f0	fix(downloads): confine download paths to the download root ... file_path and target_dir reached PathBuf::join unchecked from the frontend, and mark_download_completed stored a caller-supplied path that is later fed to remove_file. A correct sanitiser already existed — download_item_and_start used it — but download_item is itself a command taking file_path raw, so the guard was simply routed around. It now lives inside download_item, alongside a join-then-confine check modelled on media_server::resolve_path. Sanitising is per path component, not whole-string: the latter would silently turn downloads/x.mp3 into downloads_x.mp3 and relocate every existing download. TRACES: | DR-211 | UT-205	2026-08-20 20:03:04 +02:00
dtourolle	b313b61717	fix(repository): bind query parameters and encode URL values ... Three consistency fixes, each one applying a pattern the same file already used a few lines away: the offline get_items type filter now binds placeholders like search at offline.rs:1786 does, build_get_items_endpoint percent-encodes its values like the Genres block below it does, and player_set_volume clamps NaN and out-of-range input at the command boundary rather than relying on each backend to do it. TRACES: | DR-212 | UT-206	2026-08-20 20:02:57 +02:00
dtourolle	da6b039b29	fix(downloads): confine download paths to the download root ... Both halves of the path a download writes to arrived from the frontend unchecked. `start_download` and the queue pump built their target as `PathBuf::from(target_dir).join(file_path)`, and `mark_download_completed` stored a frontend-supplied `file_path` on the row verbatim — the same column that is later read back into `std::fs::remove_file` when a download is deleted. A correct sanitiser already existed and `download_item_and_start` used it, but `download_item` is a command in its own right, so calling it directly routed the guard around. The guard moves inside. `confine_to_root` folds `..` away lexically and requires the result to sit inside the storage root, modelled on `media_server::resolve_path` — the check comes after the join because `Path::join` drops the base when the joined half is absolute, so an absolute `file_path` is obeyed rather than folded. `confine_queued_path` sanitises a queued path per component (so the already-safe name `download_item_and_start` passes in is not sanitised into a second, different one) and confines it. Applied in `download_item`, at both join sites, and to what `mark_download_completed` writes. Every path the app builds for itself is returned unchanged, including the absolute ones `download_series`/`download_season` produce from `${targetDir}/videos`, so no existing row or file on disk is orphaned. The pump fails an offending row rather than skipping it, because the pump re-queries and would otherwise not terminate. Not a live vulnerability: reaching these commands with hostile input needs script execution in a webview whose CSP is `script-src 'self'`. This is hardening and consistency. TRACES: DR-211 | UT-205	2026-08-20 20:01:52 +02:00
dtourolle	080cdbf383	fix(player): clamp volume at the command boundary ... player_set_volume passed `volume` through untouched. Each backend clamps to 0.0..=1.0 for itself, so local playback was already safe, but the remote branch reaches no backend: it converts with `(volume * 100.0) as i32`, which turns infinity into i32::MAX. NaN is handled explicitly since f32::clamp returns NaN for a NaN input and it then survives every comparison downstream. TRACES: DR-212 | UT-206	2026-08-20 20:00:35 +02:00
dtourolle	55b37ba2f4	ci: make clippy a hard gate ... The advisory step existed because the tree carried a warning backlog. Measured on 1.97.1 — the pinned toolchain CI actually uses — that backlog is three warnings, not the ~51 the comment claimed: two unnecessary_sort_by in smart_cache and one redundant into_iter in offline. Fixed, so clippy now runs with -D warnings and a warning means new breakage. Worth recording why this took a toolchain pin to do safely: the same tree measured 0 warnings on 1.92.0 and 3 on 1.97.1. Flipping the flag on a local measurement, without the pin, would have reddened CI on the next push. TRACES: | DR-206	2026-08-20 19:58:39 +02:00
dtourolle	ac3cd67164	feat(library): exclude chosen folders from music browsing ... Replaces `src/lib/utils/podcastFilter.ts` — a shipped personal workaround that dropped any item whose name, album, album artist or artist was literally "Podcasts" — with a real user setting applied in Rust. The old filter was wrong twice over: it hardcoded one user's folder layout keyed on an English literal, and it put a domain rule (what a query should return) in the presentation layer. It slipped past `check:boundary` only because it matched on names rather than on an item-type array. - `repository::exclusions` owns the rule and the process-wide id set, the same shape as `online::STREAMING_QUALITY` so it survives a repository being rebuilt on re-login. - `HybridRepository` applies it where the cache and server legs of every cache-first query converge (`parallel_race` / `race_with_refresh`), plus the bespoke `get_items` path and the server-only reads. Filtering before the "has content" check is what makes a cache page of nothing but hidden items fall through to the server. - Exclusion is by stable item id, never by name, and matches an item's own id or any container link it carries (parent, album, library, series, season, artist). - A direct `get_item` lookup and the Downloads surface are deliberately unfiltered: hiding those would break playback and file management of anything inside a hidden folder. - `LibrarySettings` persists to `app_settings` and is restored in the setup hook, alongside the streaming-quality cap. Default is an empty list — nobody inherits the old "Podcasts" behaviour. - New commands `library_get_settings`, `library_set_settings` and `library_get_exclusion_candidates`; the candidates read goes through `get_items_unfiltered` so an already-hidden folder still appears in the picker and the setting can be undone. - Settings page gains a "Hidden Folders" section that renders the backend's candidate list and sends back ticked ids; it decides nothing. TRACES: UR-076 | DR-209 | UT-203	2026-08-20 19:38:05 +02:00
dtourolle	889289286b	merge: clear the clippy backlog and unify lock helpers (D1-warnings, D3) ... 51 clippy warnings -> 0, with 8 justified #[allow]s (IPC arity, specta wire types, and the 9 test-only await-holding-lock sites). 27 raw lock calls moved to the poison-tolerant helpers - all of them test code; production was already clean. Caught a non-neutral clippy --fix: removing the redundant 'use hostname;' in credentials.rs orphaned its #[cfg(target_os = "linux")] onto SERVICE_NAME, which would have cfg'd the constant out of every non-Linux build. Compiles clean on Linux, so only Windows/macOS CI would have caught it.	2026-08-16 23:06:33 +02:00
dtourolle	8500da1a42	chore(rust): clear the clippy backlog and finish the poison-tolerant lock sweep ... `cargo clippy --all-targets` went from 51 warnings (23 in the lib) to zero. Most were mechanical — needless borrows, `assert_eq!` against a bool literal, `vec!` where an array does, `or_insert_with(Vec::new)`, a loop index used only to index — and were applied with `clippy --fix`, then reviewed line by line. That review caught one auto-fix that was *not* semantically neutral: dropping the redundant `use hostname;` left its `#[cfg(target_os = "linux")]` orphaned directly above `SERVICE_NAME`, which would have silently cfg'd the constant out of every non-Linux build. Removed the stray attribute with the import. Where a lint asked for a risky change rather than a better one, it is suppressed with a comment saying why: - `too_many_arguments` on five `#[tauri::command]` handlers and `ThumbnailCache::save_thumbnail` — most of the arity is `State<'_, _>` injection, and a parameter struct would change the IPC contract and the generated TypeScript for no readability gain. - `large_enum_variant` on `PlayerStatusEvent` and `AutoplayDecision` — both are serde + specta wire types emitted a handful of times a second, never bulk allocated; boxing would have to stay invisible to the generated bindings while every match arm gained a deref. - `await_holding_lock` on the `hybrid`/`offline` test modules — the guard is a test-only serialisation lock for the process-global `INCLUDE_CATALOG_BROWSE` flag, and the await it spans *is* the critical section. Each `#[tokio::test]` gets its own single-threaded runtime, so this is not the production deadlock class the lint targets; restructuring would reintroduce the flag race. Real fixes elsewhere: `JellyfinItem::to_media_item` takes `self` by value, so it is now `into_media_item`; the five-tuple episode row in the download commands has a named `EpisodeRow` alias; the mpv `PropertyChange` arm matches `name: "pause"` instead of guarding on it. Also converted the last 27 raw `.lock().unwrap()` call sites to `lock_safe()`, completing the `MutexSafe`/`RwLockSafe` convention. All of them turned out to be in test modules — production code was already clean — so this is consistency rather than a fix. The two raw locks in `utils/lock.rs` stay raw on purpose: those tests deliberately poison a mutex to prove the helpers recover from it. Pure refactoring: all 698 tests still pass.	2026-08-16 23:05:13 +02:00
dtourolle	ebf9a99b80	docs(traces): tag the twelve "Done but untraced" requirements, and stop the matrix over-reporting ... Twelve requirements were marked Done in docs/requirements.md with zero TRACES anywhere in the tree. The features work — the tags were simply never written — so the matrix over-reported on exactly the requirements a reviewer would most want to verify. Each is now tagged at the code that actually implements it: - JA-006 / JA-009 / JA-013 / JA-014 / JA-015 / JA-018 and IR-022 / IR-024 at their Jellyfin call sites in repository/online.rs (search, get_item's MediaStreams/People fields, Items/Resume, Shows/NextUp, FavoriteItems DELETE, get_person/get_items_by_person), plus the commands that expose them. - UR-006 / IR-006 across the lockscreen spine: JellyTauPlaybackService (the MediaSessionCompat owner), the nativeOnMediaCommand JNI intake, and LockscreenMetadata / update_lockscreen_metadata. - IR-008 at both audio-focus mechanisms — ExoPlayer-managed for audio, the manual AudioFocusRequest listener for video — and at the media-type string that chooses between them. - UR-037 (with DR-042, also untraced) on the video-library poster grid: LibraryGrid, MediaCard, and the tv/movies routes. Resolve contradictory statuses across layers, evidence first: - IR-018/IR-019 were Planned under Done URs because they were scoped to libmpv. MpvBackend is the audio-only backend and overrides neither set_subtitle_track nor set_audio_track — the trait's not_implemented() default still stands — so UR-020/UR-021 are met by ExoPlayer and by the HTML5 <video> path instead. Both IRs are re-scoped to those backends and marked Done; IT-008/IT-009 and the stale @req-planned markers in backend.rs follow. - IR-005 (MPRIS) stays Planned: there is no MPRIS/D-Bus code or dependency in the project and update_lockscreen_metadata is a no-op off Android. UR-006 is corrected to Done (Android) rather than the IR being marked Done. - A note under the IR table records where a UR is met by a different mechanism than its IR anticipated. Define the two dangling IDs the source already referenced: DR-189 (the control bar never auto-hid on a touchscreen, because its timer was armed only from onmousemove) and UT-188 (its rule test). The live-denominator assertion in extract-traces.test.ts moves 187/330 to 188/331 accordingly. Traced requirements 444 to 459; IR coverage 19/32 to 25/32.	2026-08-16 22:58:55 +02:00
dtourolle	c0c6c5023e	fix(player): resume a transcoded video by seeking, not by asking for a stream that starts mid-item ... A resumed transcode played nothing at all: every segment came back 400, hls.js exhausted its retries and gave up, while the same episode from the beginning was fine. Jellyfin builds each segment URI by echoing the master playlist's query string into it, and its segment handler opens by rejecting any request carrying StartTimeTicks > 0 (ArgumentException → 400). So one resume position on the playlist is copied onto every hls1/main/N.ts and 400s all of them — the `> 0` being exactly why starting from the beginning survived. HLS does not need the parameter: a playlist spans the whole item and asking for segment N *is* the seek. It is removed from the URL builder entirely rather than conditionalised — the builder cannot know whether its response will be segmented — and the position becomes a seek issued once the player has loaded. The progressive /Audio/universal builder behind the background-audio handoff has no segments and keeps its StartTimeTicks, which is why audio-only handoffs resumed correctly and video ones did not. Completing that across the boundary, since the URL no longer starts where the caller asked: - reloadSource(url, position) now means "reload and resume AT this absolute position": it seeks the element once the source is playable and clears the transcode offset to zero. It previously set the offset to the position and seeked nothing, which was correct only while the URL itself began there — left in place it would have shown 20:00 on the scrubber while the opening titles played, with no seek ever happening. - The transcoded resume path in the player page collapses into the same "seek after load" branch direct streams already used. - VideoPlayer's background-audio return does the same: no base, seek to the absolute position. - The stale test asserting StartTimeTicks is present is rewritten to keep its other half (an HLS master playlist, never a progressive stream.mp4, carrying the chosen source and audio track). TRACES: UR-004, UR-005, UR-019, UR-021, UR-074 | DR-181 | UT-182, UT-183	2026-08-16 11:08:42 +02:00
dtourolle	de1c13e72f	fix(player,reporting): report real positions, and count an audio-only episode as watched ... Returning to the foreground before the background-audio stream had started playing handed the frontend 0.0s, so the video reloaded at StartTimeTicks=0 — the episode restarted from the beginning — and the stop report that followed wrote that zero to Jellyfin as the resume point. Caught on device: locked at 18.4s, unlocked 3.5s later with ExoPlayer still IDLE. The base that turns a handoff's relative timeline into the episode's is applied once at the native tick boundary (DR-159), so before the first tick nothing has applied it. The same blind spot covers webview-rendered media, where nothing is loaded into the native backend at all and its position is a permanent 0 — which is why 14 of 14 stop reports in a 35-minute trace were zeroes, one landing 40s after the frontend had correctly reported 15:22 for the same episode. - absolute_position(): the maximum of the backend's reading, the last position webview media reported, and the handoff base. Exact rather than heuristic — at most one term is ever meaningful, and the base is a floor the stream cannot physically be behind. duration() gains the same fallback. - Withhold zero-position stop reports. A zero is never information, and Jellyfin stores the reported position as the resume point, so sending one only ever destroys a real one. - Report progress from the controller's own position ticks, through the 30s throttler it already shared with the native audio path. /Sessions/Playing/Progress was previously requested zero times in 35 minutes. - Report a finished audio-only episode stopped at its runtime before advancing, so Jellyfin's 90% rule marks it played. Nothing else can: the webview is suspended and its <video> was torn down at the handoff. - Split the handoff by source — a downloaded file takes no base and a real seek, a stream keeps its StartTimeTicks base and no seek — and stop routing a downloaded handoff's absolute seek through the stream rebuild, which refuses a non-remote source outright. Reports go through a PlaybackReportSink, which also collapses three copies of spawn-a-task-and-hope into one and is what let each of these be written as a failing test first. TRACES: UR-005, UR-025, UR-040, UR-071 | DR-178, DR-179, DR-180 | UT-176, UT-177, UT-178, UT-179, UT-180, UT-181	2026-08-16 10:23:00 +02:00
dtourolle	1a9805f0f3	fix(downloads): queue the whole album, and make every queued track findable offline ... An album download put a handful of its tracks on the device while the button reported the album as downloaded. Two independent gaps, one shared cause. - `download_album` read its track list from `items WHERE album_id = ?` — the local catalog cache. Jellyfin does not return `AlbumId` on every listing endpoint, so tracks cached from one of those sit in `items` with a NULL `album_id` and are invisible to that query. On the reported database three whole albums (18, 12 and 9 tracks) had it NULL on every track; a partially linked album queued only the linked subset. - The frontend then resolved one stream URL per track from its own list and paired it with the returned row ids by position. The ids came back in the backend's `index_number` order over a different set of rows, so a row could be handed another track's URL and any track past the end of the shorter list was never started. On Android that loop also stopped wherever the webview was suspended. - `album_id` is what `OfflineRepository::get_items` joins a track to its album on, so a track that did download stayed invisible under its album offline — the same missing link seen from the other side. The operation now belongs to Rust end to end: - `HybridRepository::get_album_tracks` asks the server what the album contains. Cache-first `get_items` is right for browsing and wrong for deciding what to download; it errors offline so the caller falls back to the ungated local catalog, keeping the queue-while-offline flow. - `queue_album_tracks` writes the album link onto every track it queues, and creates an `items` row for tracks the cache has never seen. - Stream URLs resolve here, through the existing reconnect resolver, now scoped to the rows just queued so one album cannot start every unrelated pending row. Only the album id crosses the IPC boundary. - `album_file_names` gives each track its own file. A title repeated inside one album (deluxe edition, two discs) mapped to one path, so those downloads overwrote each other. Re-tapping download on a broken album heals it: missing tracks are queued and the tracks already on disk get their link. `download_series`/`download_season` still derive their episode lists from the cache the same way and want the same treatment. DR-173, UT-170..172. Rust 673 tests, frontend 975 tests, svelte-check and check:boundary clean. Note: this tree is shared with a concurrent session. Only the files above are committed; docs/traceability.md is left to be regenerated once that work lands.	2026-08-16 09:20:32 +02:00
dtourolle	ac4fccd499	fix(downloads,playback): re-encode undecodable audio and carry the media source through ... Work from a parallel session in the same working tree, committed here so the branch is not left half-written. Attribution note: authored in a concurrent Claude session, not by the author of the preceding commit. - DR-171: a downloaded video keeps audio the device can actually decode. `original` quality asked for a straight copy, so an E-AC-3/AC-3/DTS/TrueHD track came down untouched and the webview had nothing to play it with. - `get_video_download_url` gains the media source, so the URL is built against the source actually chosen rather than the item's default. - Device profile and repository plumbing updated to match. Verified green as a whole: 656 Rust tests, 945 frontend tests, svelte-check clean.	2026-08-15 23:54:00 +02:00
dtourolle	a5535f2941	fix(downloads): stop libraries mixing, make pause/resume real, reap partials, end bitrate corruption ... Four defects behind "downloads still flaky", each with its own cause. Libraries mixed their media (DR-167). Cached items carry no link back to their library — library_id and parent_id are NULL on every row — so the library branch of get_downloaded_items matched `EXISTS (SELECT 1 FROM libraries WHERE id = ?)`, which asserts only that the library exists and never constrains the item to it. Opening any downloaded library listed every downloaded top-level item on the server: films under Music, albums under TV. The query deciding which libraries appear already had the right rule, so the two disagreed about the same question; that collection_type <-> item_type mapping is now one constant used by both. Pause and resume did nothing (DR-168). pause_download wrote status = 'paused' and stopped there — no cancellation existed anywhere in the download stack, so the streaming task ran on and overwrote the row with completed/failed when it finished. The row flicked to "paused" and undid itself. resume_download had the mirror defect: it flipped the row to 'pending' without pumping, and the pump is not a poller, so a resumed download sat until some unrelated event pumped the queue. Adds a per-download stop flag the worker reads between chunks and on retry, returning Stopped — not retryable, not recorded as a failure, and the .part file is kept because that is what the resume continues from. Registering returns a fresh flag so a resumed download does not inherit the pause that stopped it. Cancel and clear_stale_downloads signal it too, so neither deletes a file still being written. Partial files were never reaped (DR-169). The worker named its sidecar with with_extension("part"), which replaces: movie.mp4 became movie.part. Every cleanup path deleted "{file_path}.part" — movie.mp4.part. They never matched, so the partial of every cancelled or failed download stayed on disk forever, invisible to disk-usage totals because no row pointed at it. One partial_path helper now serves the writer and the cleaners. Bitrate downloads corrupted themselves (DR-170). Only `original` asks for Static=true; every other rung requests a transcode, which Jellyfin serves chunked with no Content-Length and cannot byte-seek — it ignores Range and answers 200 with the whole stream, not 206 with the tail. The worker sent the header whenever a .part existed and appended the body regardless, so each retry concatenated another full copy onto what was on disk. The file grew past its real size and would not play, which is why bitrate downloads stayed broken after the videoBitRate casing fix corrected the request. resume_offset now lets the response decide: append only on 206, otherwise truncate and take it from the top. docs/requirements.md also carries DR-171/UT-166, written by a parallel session working in the same tree; its code lands separately.	2026-08-15 23:52:02 +02:00
dtourolle	d49d027020	docs(player): allocate UR-074/DR-162 for the streaming bitrate cap ... The feature shipped tagged against DR-160, which a parallel session had claimed for picture-in-picture in the meantime. Renumbered to DR-162 across the Rust and frontend TRACES comments (the PiP tags in VideoPlayer.svelte, pictureInPicture.ts and nativeVideo.ts keep DR-160) and regenerated bindings.ts. Adds the requirement rows the tags point at: UR-074 for the user need, and DR-162 covering why the cap has to reach the PlaybackInfo negotiation and not only the transcode URL, why the ceiling is process-wide, and why the Settings default persists while the in-player override does not. Notes that this gives UR-070 its resume-at-the-same-point mechanism while the server-offered rendition list that requirement also asks for stays proposed. UT-156/157 record what the tests pin. docs/specs/streaming-bitrate-cap.md carries the layer assignment — the step definitions, the video/audio split, the resolution pairing and the reload decision are all Rust; the frontend holds a serde token and the labels it was handed. TRACES: UR-074 | DR-162 | UT-156, UT-157	2026-08-15 16:39:53 +02:00
dtourolle	dda2ff86a3	feat(player): cap streaming bandwidth with a user-chosen bitrate ceiling ... Video streams were opened at a fixed allowance nobody could change: MaxStreamingBitrate=20000000/VideoBitrate=18000000 on the HLS transcode URL, 20 Mbps in the PlaybackInfo negotiation, and a 999999999 device profile that let the server direct-play a source of any size. On a metered or slow connection there was no way to spend less. StreamingQuality is a ladder of bandwidth ceilings — Original, 20/10/8/ 4/2/1 Mbps and 720 kbps — where a step bundles the total ceiling, the audio share of it and the resolution that budget can carry. Those numbers are Jellyfin encoding vocabulary, so they live in Rust and the frontend only names a variant; labels and details come back over IPC from player_get_streaming_qualities, the same arrangement as the EQ presets. The cap has to reach the *negotiation*, not just the transcode URL: max_static_bitrate in the device profile is what makes the server refuse to direct-play a file fatter than the cap, and without it a 30 Mbps remux is handed over untouched and every URL parameter downstream is moot. So it is applied at all four places that decide bandwidth — the HLS URL builder, PlaybackInfo, the Live TV stream, and the background-audio handoff (which takes the lower of the cap and its own 384 kbps). Video bitrate is the total minus the audio share so the two together honour the ceiling rather than overshooting it. The ceiling is process-wide rather than a repository field: it is a preference about this device's connection, must survive a repository rebuilt on re-login, and every URL builder plus the negotiation have to agree on it or the cap leaks. Same shape as INCLUDE_CATALOG_BROWSE. Two ways in. Settings holds the durable default, persisted to app_settings and restored at startup — unlike the rest of VideoSettings, because a limit set for a metered connection that silently reverts to uncapped on the next launch spends the user's data with no changed setting to see. The in-player menu is the "this film, this connection" override: a cap is a property of the stream the server is producing, so it cannot apply to one already in flight — player_set_stream_quality re-opens the stream at the new quality and resumes at the current position, reloading the native backend itself and handing HTML5 a URL for the same reloadSource primitive the audio-track switch uses. Tests pin the URL parameters at a capped and an uncapped step, the handoff taking the lower of the two, the ladder's internal consistency (video + audio == cap, resolution descending with bitrate) and the persisted token's round trip. The ceiling is process-wide, so the tests that depend on it serialise on a guard that restores the default. TRACES: UR-074 | DR-160 | UT-156, UT-157	2026-08-15 16:34:56 +02:00
dtourolle	9f5f57cba4	fix(ui,player): scroll restore, immersive fullscreen, watched toggle, handoff timeline, PiP ... Batch of reported bugs and enhancements. UI - Pages no longer inherit the previous page's scroll position (DR-156, UR-072). The shell keeps its scrollers alive across navigation by design, so the element never remounts and its scrollTop survived the route change; SvelteKit restores window scroll, which this app never uses. ScrollMemory records the offset per route and per container: forward moves reset to the top, Back restores where the route was left. - Season header stacks on narrow screens, and the title span gets min-w-0 so it actually truncates instead of overflowing under the action buttons. - Favourites gets a labelled tile at the head of the library grid rather than only an unlabelled heart icon in the header. Playback - Full-screen video on Android hides the system bars (DR-157, UR-066). requestFullscreen() cannot touch the Activity window from inside a WebView, so the control did nothing visible while the bars stayed painted over the video. ImmersiveModeBridge hides them, restored on exit, Escape and teardown. - Background-audio handoff stops leaking its relative timeline (DR-159). background_audio_base was a display-only correction applied in two places while progress reports to Jellyfin, the frontend and media3's own seeks all worked in the relative timeline treating it as absolute — each crossing losing exactly `base` seconds. The conversion now happens once, in the position tick, and inbound seeks resolve through seek_absolute, which re-opens the stream at the requested position because the handoff transcode cannot seek. - Picture-in-picture works on the path that actually plays video (DR-160). canEnterPip demanded a native ExoPlayer surface, but that path is behind a flag defaulting to off, so PiP could never engage. It now accepts the WebView <video> too, keeping the WebView visible and routing play/pause to the element. - Native video is now the default so PiP has a real surface (DR-161). The scrub-regression tests pinned the flag-off path implicitly; they now mock it off explicitly. The native scrub/seek path is not covered by the suite and needs device verification. Watched state - Watched toggle on the episode row, season header, series and movie hero, and the Episode Focus View (DR-158, UR-073). Both backend halves already existed with no caller. storage_set_watched covers a container's episodes so the toggle is honest offline, and QueuedOp::MarkUnplayed gives the sync queue the missing direction. Release - Fix the Android versionCode floor (set-version.sh). v0.5.2 shipped code 5002 under an earlier minor*1000 scheme, but the current minor*100 formula yields 1502 for that version and 1503 for 0.5.3 — so every 0.5.x release built from it was an un-installable downgrade for anyone already on v0.5.2. Widened to 10000 + major*1000000 + minor*1000 + patch (0.5.3 -> 15003). - Bump to 0.5.3.	2026-08-15 16:26:31 +02:00
dtourolleandClaude Opus 5	2ca2174cea	fix(player): return volume control to the local speaker when a remote session stops ... Stopping a remote session left Android stuck on the remote volume slider with no way back to the device speaker. Two causes: 1. `player_stop`'s remote branch sent "Stop" to the session and returned without touching the playback mode, so the manager stayed in Remote. It now drops to Idle, mirroring what the local branch already does. 2. Volume routing was torn down at a single call site (`transfer_to_local_inner`), so every *other* exit from remote mode leaked the Android VolumeProviderCompat. Routing is now derived from the transition inside `set_mode`: entering remote attaches control, any exit from remote hands it back to the local media stream. This also covers the frontend `disconnect()` path (Remote -> Idle) and the local-playback-start paths (Remote -> Local). Adds a `RemoteVolumeControl` trait so the routing rule is unit-testable off-device — the real implementation is Android JNI. Tests cover remote->idle, remote->local, remote->remote (re-arms, never releases), and that local/idle transitions leave routing untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 20:09:17 +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	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	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	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	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	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	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	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	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	5927299c0f	feat(search): rank results by match quality and split TV/People groups ... Neither search backend orders by *where* the query matched, so a mid-word hit could outrank a prefix one — typing "parks" surfaced "Sparks of Love" above "Parks and Recreation". Add `domain/search_rank.rs`, which sorts by match position (prefix → word-start → mid-word substring → no name match), then by media kind so a container outranks its own contents. The sort is stable, so each backend's own relevance still breaks ties it was never overruled on. `repository_search` applies it to both the instant cache result and the merged cache+server union, so the list does not reshuffle when server results land. Ranking lives in Rust because "a better match" is domain vocabulary, not presentation. On the frontend, the combined `tvShows` result group splits into separate Shows and Episodes groups so a show no longer competes with its own episodes for a slot, and a People group is added so searching an actor's name reaches their bio. A stored `tvShows` order expands in place, keeping the position an upgrading user chose for it.	2026-07-25 15:13:32 +02:00
dtourolle	ee584aced2	fix(autoplay): advance to the next episode in background audio mode ... An episode handed off to the audio-only path for background playback is a MediaType::Audio item, so autoplay's video-only checks stopped recognising it as an episode: playback simply ended at the episode boundary instead of continuing to the next one. - Carry episode identity (item_type, series_id) through the background-audio handoff so the backend queue item still knows it's an episode; is_episode_item now trusts item_type over the media_type heuristic, and the sleep timer's episode counter follows. - The frontend normally performs the advance by navigating to /player/<id>, which is unavailable while the WebView is suspended. advance_to_next_episode_audio_only drives it entirely in the backend: fetch the next episode, build its audio-only stream URL, and load it into the native audio player, preserving episode identity so the following boundary advances too. - Android's autoplay dispatch routes background-audio episodes to that backend advance and keeps the countdown path for the foreground. - get_audio_only_stream_url_for_video joins the MediaRepository trait (online delegates to the existing builder, offline errors) so the controller can reach it without a frontend round-trip. TRACES: UR-040, UR-023 | DR-052 | JA-032	2026-07-25 09:21:08 +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	57b24f8c74	fix(offline): Downloaded browse groups by container and loads on large libraries ... Two bugs on the Downloaded browse surface (UR-055/UR-056): 1. Grouping — browsing a downloaded *library* listed individual leaves (songs, episodes) instead of their containers. The library-level match in `get_downloaded_items` selected every downloaded item on the server; add a NOT EXISTS clause so the top level shows only albums/series/movies, with leaves still reachable by drilling in. Regression tests for music + TV. 2. "Loading your downloads…" hung on large libraries. The disk-usage partiality query did an OR-based self-join over the entire synced catalog (O(items^2), unindexable). Narrow it to downloaded containers first via a CTE, and add the missing idx_items_season index (migration 020 + base schema) — parent_id/album_id/series_id were already indexed. Also annotate the existing backend tests that cover the IT-016/IT-017 end-to-end offline-listing scenarios with their trace IDs.	2026-07-24 21:42:12 +02:00
dtourolle	ec8a7610f5	domain: player/reporting ticks -> milliseconds (phase 4c) ... Playback position now crosses the IPC boundary in milliseconds. Ticks survive only inside Rust (DB storage, Jellyfin API) and at the genuine remote-session boundary (session seek / transfer / RemoteControls). Rust command signatures (ms in, converted to ticks internally): - storage_update_playback_progress / _context: position_ms - repository_report_playback_start / _progress / _stopped: position_ms - PlaybackProgress.position_ticks -> position_ms (converted in the query) Frontend: - playbackReporting, playerEvents, VideoPlayer, Queue, player/[id] resume: seconds*1000 / durationMs/1000 instead of tick math. - repository-client + syncService param names -> positionMs. - Tests updated to ms fixtures/assertions. Out of scope (legitimately ticks): NowPlayingItem, PlayState.positionTicks, sessionSeek, playbackModeTransferToLocal, RemoteControls, SessionCard — the remote Jellyfin session API. Rust 456, frontend 644, check clean.	2026-07-23 22:02:29 +02:00
dtourolle	93d198ce21	domain: primaryImageTag -> imageId end-to-end (phase 4a/4b) ... Rust: PlayerMediaItem and MergedMediaItem gain image_id (dual-carry), populated from primary_image_tag at every construction/conversion site. Regenerated bindings. Frontend: all catalog + player + merged readers now use imageId. The NowPlayingItem->MediaItem bridge (player.ts) properly maps the remote session's Jellyfin fields (Type, runTimeTicks, primaryImageTag) onto the neutral kind/durationMs/imageId. Types that are genuinely out of scope (Person, NowPlayingItem, PlayItemRequest) keep primaryImageTag. Rust 456, frontend 644, check clean.	2026-07-23 21:40:58 +02:00
dtourolle	f25deba824	feat(downloads): browsable downloaded library with on-disk usage ... Replace the flat download list with a Downloaded browse surface that reuses the online grids/cards/detail pages, filtered to on-device media, plus a demoted Transfers tab. Add repository browse commands (getDownloadedLibraries/Items, disk usage) with offline/hybrid implementations, a downloadedCatalog service, formatBytes helper, and per-item/device disk-usage labels on cards and grids. Regenerated bindings. Also carries the inseparable UR-052 offline-filter hunks in offline.rs/hybrid.rs. TRACES: UR-055 | DR-081, DR-082, DR-083, DR-084; UR-056 | DR-085	2026-07-23 20:02:55 +02:00
dtourolle	e083b53ee8	feat(downloads): WiFi-only network-type-aware download gating ... Add a metered/cellular network detector so downloads honour a "WiFi only" preference. Android reports network type via NetworkTypeMonitor; Rust exposes it through download/network.rs and holds the queue pump when on a metered connection, emitting a queue-wide waitingForNetwork event. The frontend surfaces this via the networkType service and a waitingForNetwork store flag. TRACES: UR-053 | DR-074	2026-07-23 20:02:07 +02:00
dtourolle	acf1bb200d	fix resuming video playback after background audio only mode.	2026-07-22 22:28:07 +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
dtourolle	2a1f1689b4	Layout and search fix	2026-07-11 19:55:55 +02:00
dtourolle	36be192d44	offline mode fixes	2026-07-07 16:22:12 +02:00
dtourolle	acb7e5f221	fix offline mode and layout bugs	2026-07-06 20:24:46 +02:00
dtourolle	2d141e5bf4	Fix for offline mode	2026-07-03 19:37:34 +02:00
dtourolle	1f6977cd01	Playback fix	2026-07-02 18:13:55 +02:00
dtourolle	75014ee00f	Fix sleep bug, fix menu return	2026-07-01 23:49:51 +02:00
dtourolleandClaude Opus 4.8	342f95cac1	Wire up playback reporting, fix duration flash, hide video from audio mini player ... Playback reporting (position sync / resume-on-another-device): - player_configure_jellyfin now builds a PlaybackReporter sharing the player controller's Arc, so Start/Progress/Stopped actually reach Jellyfin on every auth path (login/restore/reauth); previously they never did. - The PlaybackReporterWrapper now shares the same Arc the controller and MPV progress loop report through, instead of a dead parallel Option. - Android position callbacks now emit throttled progress reports (30s/item), mirroring the MPV backend. Duration flash on pause: - resolveDuration() prefers the live store duration for the already-loaded track over the runTimeTicks estimate, so pausing no longer clobbers the slider's max to 0 when runTimeTicks is missing. Video leaking into audio mini player: - isVideoItem() also checks the backend PlayerMediaItem mediaType discriminator, so a video started via player_play_item (no Jellyfin `type`, mediaType "video") no longer surfaces in the audio mini player. Middle-truncation of long media names: - New truncateMiddle util applied to track/episode/card/mini-player titles so distinguishing tails (episode numbers, suffixes) stay visible. Adds regression tests for the duration and mini-player fixes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-01 21:52:27 +02:00
dtourolle	0eae81ec59	Add JRay support	2026-06-28 20:38:58 +02:00