endless loop on track entries already marked as unplayable

[ciros88]

this seems to happen when loop all is enabled and a track is playing then the user tries to play a track from another playlist that is incompatible (like an m3u created in vlc) that has been copied in the bzr2 "playlists" folder.

the key point of this issue is not to add support for non-bzr2 m3u files (because, for my point of view, copy an m3u file directly into bzr2 "playlists" dir should be an illegal operation since everything should be done trought bzr2 user interface), but only to prevent endless looping on unplayable tracks (that happens in this scenario but could potentially happens also in other "legal" scenarios)

[aargirakis]

Well. Just because a track is marked as "unplayable" doesn't mean that it's unplayable the next time we try to play it. Maybe the first time you tried to play the file the network drive wasn't ready or the webstream had hiccups. So we can't just ignore files that previously wasn't playable since files (in particular webstreams) may be playable the next time. Of course in this scenario it may seem a bit weird. VLC is even worse though.

[ciros88]

vlc has been recently (FINALLY!) fixed the loop on erronous track scenario after a lot of years.... xD apart from this, yeah i understeand ur point of view, the problem here is differentiate the cause of an unplayable track. there is cause like not found (like ur webstream example), and causes like corrupted or invalid .mod . i think the cause of a playback error should be internally differentiated so you can handle differently basing of the different cause.

[ciros88]

also, another strategy is to prevent endless loopings of same retried action that doesnt arrive to a playback state: i mean, broke the loop chain (setting a maximum of loop counts like 10) if the last interation hasn't finished with a playback but with an error

[ciros88]

noticed that this scenario leads bzr2 to crash: start and endless loop play with invalid entries, then put bzr2 in the background, after seconds will close.

i can say that this crash is better than having a player opened in the background that uses your cpu in a subtle way.. so i prefer to have bzr2 crash for now until this ticket has been resolved

[ciros88]

proposal: when a file is missed, and bzr2 is in loop mode, then put it in a map (playlist specific) where map key is the tracklist entry id (uuidv4 in order to avoid any collision) and map value is invalid_loop_count var, then is increased by 1. when any of the invalid_loop_count reaches its maximum (like ie 30, taking in mind that a modern cpu arrives to 30 in instants) then the track entry will become strikethrough and forever skipped. the only chance to play it is to add the file to the tracklist again (the entry will have a new key). the map key shouldn't be based on tracklist entry/position neither on file hash for obious reasons, this is why uuidv4 is proposed here.

[ciros88]

also now that tempfile.tmp is created for unicode workaround, there is more needing to stop wasting disk writes.