You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Playback jumps back upon finish #690 "Playback jumps back upon finish" (iOS + Android, open) - the "occasionally it correctly jumps to the next episode in the queue but not reliably" part of that report is this same bug.
[Feature Request] Auto play next episode #809 "[Feature Request] Auto play next episode" (open) - filed as a feature request, but auto-advance is already intended to exist; it's just broken.
Description
On the mobile app (Android/iOS), when a playing episode finishes, playback just stops instead of advancing to the next episode in the Queue - even though the Queue tab shows episodes waiting.
Root cause
The mobile app has two separate, disconnected queue implementations:
Server-side queue (the real one) - used by the Queue tab (ui/pinepods/queue.dart) and the Up Next view (ui/podcast/pinepods_up_next_view.dart, whose own doc comment says "This replaces the local queue functionality with server-based queue management"). Episodes are added/removed via PinepodsService.queueEpisode() / removeQueuedEpisode() and fetched with getQueuedEpisodes().
Local/legacy queue - an in-memory list (_queue in services/audio/native_audio_player_service.dart), only ever populated through addUpNextEpisode(), whose only callers are in bloc/podcast/queue_bloc.dart - a bloc nothing in the current PinePods UI dispatches to anymore.
The auto-advance logic in _handleCompletedEvent() (native_audio_player_service.dart) only ever checks the local/legacy _queue. Since nothing populates it anymore, _queue.isNotEmpty is always false in practice, so playback stops instead of pulling the next episode from the server queue that the Queue tab actually shows.
This looks like a leftover from migrating the queue feature to be server-backed - the UI and add/remove paths were migrated, but episode-completion handling wasn't updated to match.
Suggested fix
_handleCompletedEvent() should fall back to the PinePods server queue (via a new PinepodsAudioService.playNextFromServerQueue(), mirroring the existing manual "tap to play from queue" flow in queue.dart) when the local legacy queue is empty: fetch the next queued episode, remove it from the server queue, and play it.
A fix for this has already been prepared and tested (6/6 unit tests passing) - a pull request will follow shortly.
Relates to
Description
On the mobile app (Android/iOS), when a playing episode finishes, playback just stops instead of advancing to the next episode in the Queue - even though the Queue tab shows episodes waiting.
Root cause
The mobile app has two separate, disconnected queue implementations:
ui/pinepods/queue.dart) and the Up Next view (ui/podcast/pinepods_up_next_view.dart, whose own doc comment says "This replaces the local queue functionality with server-based queue management"). Episodes are added/removed viaPinepodsService.queueEpisode()/removeQueuedEpisode()and fetched withgetQueuedEpisodes()._queueinservices/audio/native_audio_player_service.dart), only ever populated throughaddUpNextEpisode(), whose only callers are inbloc/podcast/queue_bloc.dart- a bloc nothing in the current PinePods UI dispatches to anymore.The auto-advance logic in
_handleCompletedEvent()(native_audio_player_service.dart) only ever checks the local/legacy_queue. Since nothing populates it anymore,_queue.isNotEmptyis always false in practice, so playback stops instead of pulling the next episode from the server queue that the Queue tab actually shows.This looks like a leftover from migrating the queue feature to be server-backed - the UI and add/remove paths were migrated, but episode-completion handling wasn't updated to match.
Suggested fix
_handleCompletedEvent()should fall back to the PinePods server queue (via a newPinepodsAudioService.playNextFromServerQueue(), mirroring the existing manual "tap to play from queue" flow inqueue.dart) when the local legacy queue is empty: fetch the next queued episode, remove it from the server queue, and play it.A fix for this has already been prepared and tested (6/6 unit tests passing) - a pull request will follow shortly.