2 Commits (749bc274b37bb23cd267abb6df0a1852a8a4a256)

Author	SHA1	Message	Date
BoulderBadgeDad	df929dc022	#809 Navidrome playback: stream via the server's API when the library isn't mounted on disk ... mlody95pl: Navidrome sync works, playback fails ("Failed to resume playback"). Root cause: SoulSync plays library tracks by reading the file off its OWN disk (/api/library/play → resolve path → serve bytes). "Report Real Path" gives the correct path STRING, but that's Navidrome's container path — the files still have to be mounted into the SoulSync container to open them, and the user's compose has /music commented out. So disk resolution 404s. Navidrome is a streaming server, so requiring a disk mirror to play from it is the real limitation. Now, when a library file isn't on SoulSync's disk and the active server is Navidrome, playback streams through the server's own Subsonic /rest/stream API — no mount needed: - NavidromeClient.build_stream_url(song_id, max_bitrate) — token-authed /rest/stream URL (mirrors build_cover_art_url; password never exposed). - /api/library/play: on disk-miss, _build_library_stream_url (Navidrome-only; uses the song id sent by the player, or a DB lookup by file_path) sets a session stream_url instead of failing. - /stream/audio: proxies that stream_url with Range passthrough so HTML5 seeking works, streaming upstream bytes through in 64KB chunks (no full-file buffering). - session state gains stream_url; the two library-play callers now send the track's server id. Disk playback is unchanged (file_path path still wins when the file resolves), so Plex/Jellyfin and mounted-Navidrome setups behave exactly as before. Tests: 7 on the URL builder (auth shape, no-transcode default, maxBitRate, guards) + 4 on the play-fallback routing (navidrome-only, passed-id vs DB-lookup, none). 200 navidrome/stream/media-server tests pass.	3 weeks ago
BoulderBadgeDad	ca90c6ae6f	Player revamp Phase 3a: extract stream state into testable per-session store ... Foundation for multi-listener playback. Today web_server.py keeps ONE global stream_state dict + one lock (web_server.py:747), so the whole server shares a single 'currently playing' — every tab/device is a remote for the same playback and two listeners collide. That global is woven through ~22 sites and isn't unit-testable where it lives. Lifted into core/streaming/state.py WITHOUT changing behavior: - StreamSession: one playback's state, dict-compatible (s['k'], s.get, s.update, 'k' in s) so existing call sites work unchanged, each with its OWN RLock so distinct sessions never block/clobber each other. - StreamStateStore: registry of named sessions; lazy + race-safe create; DEFAULT session reproduces today's exact single-global behavior. Also drop()/active_ids()/session_ids() for the eventual per-listener wiring. web_server.py now binds (DEFAULT) and . Drop-in: every .update()/[k]/.get()/ site behaves identically. _set_stream_state routes a reassign through session.replace() so the store's session stays the live object (it's effectively dead — prepare.py only mutates in place — but safe now). Honest scope: this is the PROVABLE half of Phase 3. The remaining half (3b: derive a per-browser session id, per-session Stream/ staging, executor concurrency, disconnect cleanup) is browser-coupled and can't be verified without driving 2+ live clients — deferred to a live session. The store API is already shaped for it. Tests (tests/streaming/, 33 total): - test_stream_state_store.py (19): session dict-compat, isolation, lazy create, drop rules, active_ids, concurrent-create race safety. - test_stream_state_callsite_compat.py (7): every real web_server access pattern (library/play, stream/start, status, audio guard, stop, prepare in-place mutation, set->replace) against the exact object web_server binds. - test_prepare.py +1: real prepare worker drives an actual StreamSession. 76 streaming+radio tests green; ruff clean; web_server.py parses.	4 weeks ago