Infinite recursion loop for errors encountered when playing single repeat track

[jcass77]

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?

[adamcik]

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.

[jcass77]

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?

[jodal]

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?

• A track disappears when you try to play it.
• A track is skipped every time you try to play it.

If we want to do better than this, we need to implement a way to send error messages to the clients first.

[jcass77]

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:

• when consume mode is turned on, tracks are removed from the tracklist as they are played:

  mopidy/mopidy/core/tracklist.py

  Lines 626 to 631 in 9cd43cf

  	def _mark_played(self, tl_track):
  	"""Internal method for :class:`mopidy.core.PlaybackController`."""
  	if self.consume and tl_track is not None:
  	self.remove({'tlid': [tl_track.tlid]})
  	return True
  	return False

• however if the track is not playable it will simply be logged and left in the tracklist:

  mopidy/mopidy/core/tracklist.py

  Lines 620 to 624 in 9cd43cf

  	def _mark_unplayable(self, tl_track):
  	"""Internal method for :class:`mopidy.core.PlaybackController`."""
  	logger.warning('Track is not playable: %s', tl_track.track.uri)
  	if self.get_random() and tl_track in self._shuffled:
  	self._shuffled.remove(tl_track)

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?

[tkem]

+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.

[jodal]

+1, I agree that unplayable tracks should be consumed in consume mode.

[jcass77]

I've opened a separate issue for investigating how unplayable tracks are consumed: #1358.

[jodal]

With #1358 + #1359 and #1454 + #1455, this should be covered elsewhere.