New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Infinite recursion loop for errors encountered when playing single repeat track #1221
Comments
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? |
I don't remember exactly, but I suspect that we simply don't know that they are unplayable until we try playing them. What's the least surprising behavior?
If we want to do better than this, we need to implement a way to send error messages to the clients first. |
Yes that makes a lot of sense. There is a different fringe condition that we may be able to deal with in the interim though:
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? |
+1 for removing unplayable tracks in consume mode, at least. I strongly support @jcass77's argument for this case when wearing my client-developer hat. |
+1, I agree that unplayable tracks should be consumed in consume mode. |
I've opened a separate issue for investigating how unplayable tracks are consumed: #1358. |
This is similar to #17, and the "skip-to-next-track-upon-error" code (https://github.com/mopidy/mopidy/blob/749c8baceb077f8a5155e1dab33b7154ab1ba481/mopidy/core/playback.py#L361-363) also causes an infinite recursion loop for errors encountered when playing a single track in repeat mode.
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: