Summary
Playback sometimes doesn't move on to the next episode in Next Up when the current one finishes. It's intermittent -- it depends on the state of the next queued episode at the moment the current one ends.
Root cause
PlaybackService.playNextQueued() (called from onPlaybackStateChanged's STATE_ENDED branch) resolves the queue's front entry and starts playing it. If that resolution fails, it just gives up silently instead of trying the entry after it:
feedRepository.getItem(itemId) returns null (a dangling queue entry) -> settingsDataStore.setLastPlayingItem(null, null); returnPlaybackMediaItemFactory.resolve(...) returns null -> same silent early return
The most common way resolve() returns null is the mobile-data streaming gate (issue #222): if the next queued episode isn't downloaded and the device is on cellular without "always allow streaming on mobile data" set, resolve() refuses to build a MediaItem. PlaybackService's background auto-advance has no UI to show the streaming confirmation from (by design, per the comment on PlaybackMediaItemFactory.resolve), so it just fails.
Two problems compound this:
- Neither failure branch calls
player.clearMediaItems(), so the player is left parked on the just-finished episode at STATE_ENDED -- the mini-player/UI shows a stale state instead of clearly "nothing playing."
- The blocked episode is never moved out of the front of the queue (unlike
onPlayerError's handling of a genuinely broken episode, which calls queueRepository.moveToEnd() and retries with excludeItemId), so it keeps blocking every future advance attempt until the user manually intervenes, even if a perfectly playable (e.g. downloaded) episode sits right behind it in Next Up.
Suggested fix
Mirror the existing onPlayerError pattern in playNextQueued: when the front queue entry can't be resolved, queueRepository.moveToEnd(itemId) and recurse to try the next entry (bounded, to avoid looping forever if the whole queue is currently unplayable), rather than stopping at the first failure.
Summary
Playback sometimes doesn't move on to the next episode in Next Up when the current one finishes. It's intermittent -- it depends on the state of the next queued episode at the moment the current one ends.
Root cause
PlaybackService.playNextQueued()(called fromonPlaybackStateChanged'sSTATE_ENDEDbranch) resolves the queue's front entry and starts playing it. If that resolution fails, it just gives up silently instead of trying the entry after it:feedRepository.getItem(itemId)returns null (a dangling queue entry) ->settingsDataStore.setLastPlayingItem(null, null); returnPlaybackMediaItemFactory.resolve(...)returns null -> same silent early returnThe most common way
resolve()returns null is the mobile-data streaming gate (issue #222): if the next queued episode isn't downloaded and the device is on cellular without "always allow streaming on mobile data" set,resolve()refuses to build aMediaItem.PlaybackService's background auto-advance has no UI to show the streaming confirmation from (by design, per the comment onPlaybackMediaItemFactory.resolve), so it just fails.Two problems compound this:
player.clearMediaItems(), so the player is left parked on the just-finished episode atSTATE_ENDED-- the mini-player/UI shows a stale state instead of clearly "nothing playing."onPlayerError's handling of a genuinely broken episode, which callsqueueRepository.moveToEnd()and retries withexcludeItemId), so it keeps blocking every future advance attempt until the user manually intervenes, even if a perfectly playable (e.g. downloaded) episode sits right behind it in Next Up.Suggested fix
Mirror the existing
onPlayerErrorpattern inplayNextQueued: when the front queue entry can't be resolved,queueRepository.moveToEnd(itemId)and recurse to try the next entry (bounded, to avoid looping forever if the whole queue is currently unplayable), rather than stopping at the first failure.