Problem
Found while testing the Android Auto integration (#246/#250/#247/#248) on the Desktop Head Unit: tapping the queue button on Android Auto's now-playing screen shows only the currently playing episode, not the rest of Next Up.
Root cause
Android Auto's queue view (and the media notification's own queue UI, where shown) isn't driven by this app's QueueRepository at all -- Media3 generates it directly from the player's own Timeline (Player.getCurrentTimeline()/getMediaItemCount()), via its legacy MediaSessionCompat bridge. PlaybackService deliberately never loads more than one MediaItem into ExoPlayer's own playlist at a time -- Next Up is tracked entirely externally in QueueRepository, with the next item only resolved and swapped in at the moment the current one ends or is skipped (see the comments around issue #179, #196, #240/#241's playNextQueued). Since the player's timeline only ever has one item, that's all Auto (or any other timeline-driven queue UI) can show.
Why this isn't a quick fix
Making Auto's queue view show the real Next Up list means the player's Timeline needs to actually reflect it -- i.e. loading Next Up as a real multi-item ExoPlayer playlist rather than swapping a single MediaItem at transition time. That's a genuine architecture change, not a patch:
Scope for a fix (not yet planned in detail)
- Decide how much of Next Up to actually materialize into the player's
Timeline at once (all of it? a bounded lookahead window?) balanced against the per-episode resolution/gating logic above.
- Keep
QueueRepository as the source of truth, syncing the player's Timeline to it rather than duplicating queue state.
- Re-verify auto-advance, preloading, and skip-unplayable behavior all still hold with a real multi-item timeline.
How this was found
Manual testing of the Android Auto browse tree (issue #250) end to end on the Desktop Head Unit, connected to a real device with the merged #246/#250/#247/#248 build installed.
Problem
Found while testing the Android Auto integration (#246/#250/#247/#248) on the Desktop Head Unit: tapping the queue button on Android Auto's now-playing screen shows only the currently playing episode, not the rest of Next Up.
Root cause
Android Auto's queue view (and the media notification's own queue UI, where shown) isn't driven by this app's
QueueRepositoryat all -- Media3 generates it directly from the player's ownTimeline(Player.getCurrentTimeline()/getMediaItemCount()), via its legacyMediaSessionCompatbridge.PlaybackServicedeliberately never loads more than oneMediaIteminto ExoPlayer's own playlist at a time -- Next Up is tracked entirely externally inQueueRepository, with the next item only resolved and swapped in at the moment the current one ends or is skipped (see the comments around issue #179, #196, #240/#241'splayNextQueued). Since the player's timeline only ever has one item, that's all Auto (or any other timeline-driven queue UI) can show.Why this isn't a quick fix
Making Auto's queue view show the real Next Up list means the player's
Timelineneeds to actually reflect it -- i.e. loading Next Up as a real multi-item ExoPlayer playlist rather than swapping a singleMediaItemat transition time. That's a genuine architecture change, not a patch:PlaybackServicereact to liveQueueRepositorymutations (add/remove/reorder/auto-queue eviction, issue Pre-buffer the next Next Up episode while the current one is still playing #87'sstartPreloadingQueueHead) and make late decisions per-episode (mobile-data gating at play time, issue Warn and let the user override at play-time instead of a blanket disable-streaming-on-mobile-data toggle #222; skip-unplayable-and-continue, issue Auto-advance to next Next Up episode silently stops instead of skipping ahead #240) that a pre-built multi-itemTimelinewould need to account for differently.DefaultPreloadManager's single-head preloading (issue Pre-buffer the next Next Up episode while the current one is still playing #87), the wake-lock-covered advance window (issue Fix Downloads screen duplicates and orphaned files (issues #176, #178) #179), and the skip-ahead recursion bounds (issue Auto-advance to next Next Up episode silently stops instead of skipping ahead #240'sMAX_ADVANCE_ATTEMPTS) are all built around "exactly one item loaded, resolved fresh at transition time" -- switching to a real multi-itemTimelinewould need all of that reworked, not just extended.Scope for a fix (not yet planned in detail)
Timelineat once (all of it? a bounded lookahead window?) balanced against the per-episode resolution/gating logic above.QueueRepositoryas the source of truth, syncing the player'sTimelineto it rather than duplicating queue state.How this was found
Manual testing of the Android Auto browse tree (issue #250) end to end on the Desktop Head Unit, connected to a real device with the merged #246/#250/#247/#248 build installed.