Sonos queue resync + cold-start prefetcher gate #83

Merged

bvandeusen merged 3 commits from dev into main 2026-06-04 17:36:31 -04:00

Conversation 0 Commits 3 Files Changed 4

+340 -30

3 Commits

Author	SHA1	Message	Date
bvandeusen	9a31955fa4	perf(android): gate audio prefetch on isPlaying ... Cold-start playback on a fresh install was taking ~25 s before any audio played. Logcat showed AudioPrefetcher was kicking off N concurrent CacheWriter jobs the instant setQueue updated uiState -- each prefetch a full upcoming-track download over the same OkHttp client as the current-track DataSource. Five-way bandwidth split plus parallel Coil cover fetches starved the current track until its full file body had streamed through (~12 MB at ~1 MB/s under contention). Now reconcile() observes uiState.isPlaying and starts upcoming-track prefetches only when the current track is actually playing. Cancellation of out-of-window jobs always runs so a queue switch or skip still frees the pipe immediately, even while paused. Cold start should drop from ~25 s -> 5-7 s on the user's network: just the single-stream throughput plus the one-time TLS/DNS tax. Refactored the inline reconcile body into computeTargets / cancelOutOfWindowLocked / startInWindowLocked helpers to keep ReturnCount under the detekt cap.	2026-06-04 17:29:19 -04:00
bvandeusen	e7d7cb2471	fix(android): incremental Sonos queue sync for playNext + radio-append ... The previous fix re-loaded Sonos's full queue on every uiState.queue identity change -- correct for playlist-switch (full replacement) but disruptive for in-queue mutations: playNext and radio-append would restart the currently-playing track on Sonos because removeAllTracks + AddURIToQueue x N + SetAVTransportURI re-anchors the transport. Now the resync runs a longest-common-prefix / common-suffix diff first. When the current Sonos track lies in the preserved prefix, applies the minimum-incremental SOAP operations -- RemoveTrackRangeFromQueue on the removed middle, AddURIToQueue at the same insertion point -- so Sonos keeps playing the current track and the new entries land in place without interrupting playback. Falls back to the full removeAllTracks reload when the current track is in the removed slice (playlist switch). Adds AVTransportClient.removeTrackRangeFromQueue (Sonos-specific, UpdateID=0 skips the queue-version check). Cases now covered: - Playlist switch -> full reload (current track replaced, prefix=0) - playNext insert -> 1 AddURIToQueue at the right slot - Radio-append -> RemoveTrackRangeFromQueue for old tail + N AddURIToQueue for new tracks at the end	2026-06-04 17:07:26 -04:00
bvandeusen	8017934334	fix(android): re-prime Sonos queue when user plays a different playlist ... Before: tapping a different playlist while Sonos was the active route updated the player view but Sonos kept the old queue and played those tracks (or whatever was last there). PlayerController.setQueue replaced the local ExoPlayer queue and called play(), which forwarded SOAP Play to Sonos -- but Sonos's native queue (loaded once at route selection via removeAllTracks + AddURIToQueue + SetAVTransportURI) was never touched on subsequent setQueue calls. Now: MinstrelForwardingPlayer.setMediaItems (all 3 overloads) clears holder.active + sets target synchronously so the immediately-following play() drops via isLoadingUpnp(). OutputPickerController observes uiState.queue identity changes; when target or active is non-null and the queue key shifted, it re-runs loadQueueOnSonos under the existing selectUpnpMutex and restores active when done. Sonos resync failures drop cleanly to local (selectedUpnpRouteIdInternal nulled). Doesn't touch addMediaItem / radio-append paths -- those leave Sonos's queue stale and need a separate AddURIToQueue extension hook; out of scope for this fix.	2026-06-04 17:00:24 -04:00