Closed defagos closed 4 months ago
We currently have an inconsistency at the end of playback. The current publisher preserves the last item while the queue player moves to the next item (default actionAtItemEnd
). As a result the control center displays the media which just has been finished, which does not match the player true state.
So:
How must the player behave when reaching the end of the playlist? Should the current item index be returned to nil?
Should behave according to actionAtItemEnd
. Currently we have the default behavior but later we could also expose other modes. We could either provide the built-in mode or we could add smarter modes like move forward in a playlist but pause on the last item, for example.
Should we let actionAtItemEnd be customized? (intuition: probably) Should we have built-in meaningful... If we provide built-in behaviors
Possibly later, we don't know what users need yet. Will write a story.
In general how should states evolve... We should also ensure that control center metadata is correctly updated
Related problems. Will write a separate story.
How should the player behave
Will write a separate story.
Created issues #304, #305 and #306.
As discussed with @mbruegmann and @nicolasbrunnersrf and the rest of the team:
actionAtItemEnd
property without any clever behavior..pause
we should change the player playback state to .playing
or .paused
if the user seeks back to a prior position after the player reached the end (in a paused state)..pause
case (automatically resume and advance to the next item when reaching the end, except for the last one, all with a gapless playback experience).This behavior would be consistent with other platforms:
To let apps chain between items something like the following should likely be possible, maybe with a dedicated shorter formalism:
// ...
.onReceive(player.propertiesPublisher.slice(at: \.playbackState).receiveOnMainThread()) { state in
if state == .ended {
player.play()
player.advanceToNextItem()
}
}
A short test shows that this jumps to the last item in the playlist so we probably have a minor bug when advancing to the next item is made at item end.
A dedicated implementation task has been created. Closed.
As a user I want a consistent user experience when playback ends. As a Pillarbox integrator I want to have flexibility in choosing how the player behaves when playback ends, in particular at the end of a playlist.
Acceptance criteria
The following questions have found an answer:
nil
?actionAtItemEnd
be customized? (intuition: probably)actionAtItemEnd
to get the behavior they want. For example:actionAtItemEnd
directly?actionAtItemEnd
? E.g.:actionAtItemEnd
or built-in behaviors, if any? Same question if the last item, whose end has been reached, is moved elsewhere in the playlist.Expected output:
Hints (for stories)
testCurrentItemIndexAfterPlayerEnded
) might have to be updated or added in the process.Tasks