Support and General Use > Audio Playback, Database and Playlists
Dynamic playlist odd behavior
iPodVT:
For quite a while (months at least) I have been seeing the behavior that when a dynamic playlist plays to completion, the Resume Playback item in the Main Menu often yields a "Nothing to resume" message even though when I subsequently go to start playing something else I get the "Erase dynamic playlist? SELECT = yes Any Other = no" msg. But it didn't seem to happen consistently enough to be able to confidently provide a report that would definitely demonstrate the behavior. Today I noticed a new wrinkle that I seem to be able to reproduce consistently, and it's happening with various recent dev builds including today's [186ad1234b-241231] on ipodvideo and on ipod6g (both 6th and 7th Gen Classics). Here are the steps with which I am able to reproduce the behavior:
Go into any playlist in the Playlist Catalog.
Long click on any track in that playlist.
Click on Playing Next…
Click on Play.
Go into the WPS.
Let the track play to completion - it's okay to FFWD it to just before its end and then let it play out the rest of the way.
After the track finishes playing, go to the Main Menu and click on Resume Playback - see the "Nothing to resume" msg.
Long click on Playlist Catalog in the Main Menu.
Click on View Current Playlist.
At this point you might see a playlist with the single track you just played (in which case, why did I get the "Nothing to resume" msg?), or you might see a playlist with a single track containing the name of the iPod's HDD as it would appear in the macOS Finder (see the screen dump attached to this post).
Go back into any playlist within the Playlist Catalog.
Long click on any track.
Click on Playing Next…
Click on Play - see the "Erase dynamic playlist? SELECT = yes Any Other = no" msg. Again, why did I previously get the "Nothing to resume" msg?
Click anything other than SELECT.
Go back to the Main Menu.
Long click on Playlist Catalog.
Click on View Current Playlist.
Now you should definitely see a playlist whose single track contains the name of the iPod's volume (again, see the screen dump attached to this post).
iPodVT:
I tried the same sequence and got the same results with both an ipodmini2g running a7cfee640d-240908 and an ipodcolor running 7ea64a315b-241124.
chris_s:
Thanks for the report. The weird playlist content should be easily fixable (on devices with large plugin buffers at least, such as the iPods). The other inconsistencies you've mentioned can certainly be improved as well. I'll take a look later. There's probably a few things going on:
1) When playback is stopped, the Playlist Viewer "borrows" the current playlist's (index) buffer for temporarily storing the indices of an opened playlist file, instead of using the plugin buffer, as it would otherwise.
This is known unsafe behavior. The rationale behind this was probably for devices with very small plugin buffers to allow them to display larger playlists (when stopped).
As a result, you'll get undefined behavior if you start a *different* playlist without leaving a list that is displayed in the Playlist Viewer when playback is stopped. Which is what's happening when you used Playing Next... -> Play.
It also means that, after a playlist finishes playing, unless it has first been resumed from the control file again, we have to assume its indices are unusable, because in the meantime you may have opened some other playlist in the Viewer. At the moment, the Playlist Viewer only resumes a current playlist from the control file when it *hasn't* finished, though.
2) The "Nothing to resume" message is a bit misleading. It may mean that you've finished a playlist, and the resume index was set to -1. It would be just as valid to reset the resume index to 0 instead, and start the playlist all over again, even if a device has been restarted in between (that's actually the behavior I prefer on my own devices).
3) Apparently the "Erase dynamic playlist" warning has no check to see whether the resume index is -1 at the moment
iPodVT:
Thanks very much for your reply and comprehensive explanation.
The oddest behavior in my 'demo' seems to be triggered by using the 'Playing Next…' and 'Play' context menu items. If I start playing a playlist with a simple short SELECT click on a track in the playlist, then after Play has completed, View Current Playlist displays the playlist that just completed - not the HDD name - and when I go to start another playlist playing (again with a short SELECT click) I don't get the "Erase dynamic playlist?" query. In that sequence, the oddity that remains is the coexistence of "Nothing to resume" and a fully displayed playlist in View Current Playlist (which you have already explained).
chris_s:
Yeah, by selecting a track from the playlist, the displayed playlist literally *becomes* the current playlist, so a shared buffer wouldn't create any conflict at all. And, as long as you haven't modified the playlist (either before or after selecting a track for playback), you will not get a warning when trying to replace it, either.
But when choosing Playing Next -> Play from a track's context menu, the playlist that starts playing will be different from the displayed one. So when both share the same index buffer, that's bad. Doing anything using the Playing Next... menu always marks the current playlist as "modified", even if a fresh playlist was built, which is why you get warning in that case when trying to replace the playlist. May make sense to still adjust that behavior...
I've submitted two patches now, so hopefully the major issues you've mentioned are fixed in the latest dev build fe78b07db6... lmk if it doesn't behave as expected :)
Navigation
[0] Message Index
[#] Next page
Go to full version