[AmyJeanes]

Summary

Playlist tracks that arrive through sync or import often have no length, view count or upload date: Android's sync payload carries no views or date, and relative dates like "7 hours ago" are frozen at sync time. Those tracks showed no length badge, never got fixed, and sorted badly. The playlist page now fills them in from each video's details, ported from Flow-Android.

• playlistEnrichment.ts (new): which tracks need details (needsEnrichment) and how fresh details merge into a stored track (applyVideoDetails), plus Android's limits.
• usePlaylistDetails.ts: enrichTracks runs one pass per visit for playlists stored in the library: at most 50 untried tracks, one lookup at a time in chunks of 5 with a 300 ms pause. Each chunk is saved as it arrives, and the pass stops when the playlist leaves the screen.
• playlistLibrary.ts: updateStoredPlaylistTracks takes an updater, so a chunk is applied to what is stored at that moment and a reorder or removal made during a pass survives. It skips the write when nothing changed, and keeps a saved playlist's full count ("411 videos") instead of overwriting it with the number of stored tracks, which for a playlist saved before fix(playlist): page past 100 videos, channel search pages and reply threads #160 is only the first page.
• PlaylistDetailsPage.tsx: sorts and reorders the hook's list directly instead of a local copy, which every enriched chunk overwrote, undoing a drag made during a pass.

Android parity. Ported from PlaylistDetailViewModel.enrichStubs (same 50-track limit, chunk size, pause, one pass at a time, failures skipped). Differences:

• Android only picks tracks with an empty title; titled Watch Later tracks are refreshed once, ever, by its separate WatchLaterMetadataMigrator, so tracks synced in after that stay incomplete. Desktop picks any track missing a length, view count or upload date, on every visit and in every stored playlist, which covers the migrator's case without a one-time job.
• Android's updateVideoMetadata overwrites stored fields; here a field the fresh details lack keeps its stored value.
• Results are saved per chunk rather than per video, because the desktop library is one stored JSON blob.

Related issue

None filed.

Change type

• Bug fix
• Feature
• Refactor or maintenance
• Documentation
• Build, packaging, or CI

Validation

Windows 11 x64.

• pnpm test (75 files, 377 tests passed)
• pnpm build
• cargo fmt --manifest-path src-tauri/Cargo.toml --all -- --check (no Rust changes)
• cargo clippy --manifest-path src-tauri/Cargo.toml --all-targets --all-features (no Rust changes)
• cargo test --manifest-path src-tauri/Cargo.toml --all-targets --all-features (no Rust changes)
• I smoke-tested the affected desktop behavior.

Smoke test against a main build, with the same saved 100-track playlist stripped of lengths, views and dates in both: on main nothing fills in. On this branch the tracks fill in one at a time (about one every 3 s on current main) and are saved as they arrive; a visit stops after 50 lookups and the next visit continues, leaving a visit mid-pass stops it. A drag reorder made during a pass is kept on screen and in storage, the saved count stays "411 videos", and two videos YouTube won't return details for stay blank without breaking the pass. A real Watch Later synced from Android on main had 11 of 41 tracks with no views and frozen relative dates. Retested after rebasing onto #160: the same results, a playlist not in the library still makes no lookups and pages as before, and a newly saved 1009-video playlist looks up only the tracks missing details.

Screenshots or recordings

main first, then this branch:

playlist-enrich-demo.mp4

Risk and compatibility

Frontend only, no migrations or new strings. Network: up to 50 video-details lookups per playlist visit, one at a time at Android's pace, only for playlists stored in the library and only for tracks still missing details; tracks that fail are not retried until the next visit.

AI disclosure: This PR was largely written by Claude (Opus 5.5) but was fully reviewed and tested by myself before raising this.

• No new secrets, private data, telemetry, or broad Tauri permissions were introduced.
• User-facing documentation was updated where needed. (not needed)
• Dependency and lockfile changes are intentional and limited to this PR. (none)
• Breaking changes and upgrade steps are clearly documented. (none)