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
I've submitted a pull request which adapts the code to just remove these unplayable tracks from the tracklist (similar to what is being done in shuffle mode currently), see: PR #1205.
It does however raise the question of whether there should be a more elegant way of dealing with error conditions and notifying the front-end user, instead of just swallowing the errors and skipping to the next track in the back-end?
The text was updated successfully, but these errors were encountered:
I was looking at this again today. I'm currently considering if we should have tracklist keep all unplayable TLIDs and then skip them in eot/next/prev track. Meanwhile this is kinda waiting for EOT track handling taking unplayable tracks into account.
I can see how one could abstract all of that away from front- and backend extension developers and still keep the unplayable TLIDs.
What would the use case be for hanging on to unplayable tracks though? It will make the code a little more complex and the tracklist a little less intuitive to use, and I'm not sure what one would be able to do with them down stream?
"""Internal method for :class:`mopidy.core.PlaybackController`."""
logger.warning('Track is not playable: %s', tl_track.track.uri)
The result is that, when playing a tracklist in consume mode, the user can end up in a situation where the only tracks left and show in the tracklist are the unplayable ones. This seems counter-intuitive and a little surprising, as one would expect the tracklist to be empty after having run through all of the tracks with consume turned on.
What are your thoughts? If there is agreement on the idea that unplayable tracks should be removed from the tracklist in consume mode just like regular tracks then I will open a new issue and start working on a PR?