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

[Frankenpod]

The way playlists (and user-made dynamic changes to them) have changed behaviour over the last few years has left me a bit confused as to how it all currently works, to be honest.]

  Though it doesn't arise much as I mostly just play through playlists I pre-prepared on the PC and exported and don't amend them on-the-fly very often.

[iPodVT]

THANKS, chris_s!  That clarifies a lot of things for me because I often edit the current/dynamic playlist by moving, adding, and removing entries.  Now I know when to expect to see the "Erase dynamic playlist?" query, and what previously seemed inconsistent I now understand.

There's one nuance I'm still not clear about:  in the manual I see lots of references to "current playlist" and "dynamic playlist" and a few to "current dynamic playlist".  If the distinction between these can be described in a sentence or two, that would be great.  Otherwise please save your time for more pressing things and I'll spend some more of my time trying to sort it out from the manual.

[chris_s]

I'm pretty sure the manual (and probably the UI itself) still isn't totally consistent on that.

My mental model looks something like this:

The current playlist refers to whatever playlist is playing, paused, or can be resumed. It may or may not be "dynamic".

A dynamic playlist usually refers to a current playlist that is not represented by a playlist file on disk.

Current dynamic playlist mostly seems to be  used interchangeably in the manual with "current playlist" (and should probably be changed to that), but sometimes refers to a current playlist that does not have an on-disk representation.

[iPodVT]

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

I just tried it and the HDD name no longer gets displayed as the track name in View Current Playlist.  As well, I no longer get the "Erase dynamic playlist?" query, though I'm not sure how I feel about that because I actually did create/edit a new/changed dynamic playlist.  I need to play with and think about these things more, but my first inclination is that a current playlist that has finished playing maybe ought to be replayable, and an edited or newly created dynamic playlist probably ought not be erased without first querying the user if that user has set the "Warn when erasing dynamic playlist" setting to 'yes'.  But again, I need to use it and think about it some more before expressing a definitive opinion.

Thank you again, and also for the explanation re current and dynamic playlists.

[chris_s]

You may also notice that the warning message for replacing a modified playlist does not appear after you've restarted, unless the playlist has been resumed first. It's always been like this and has always bothered me, since I hate accidentally erasing a dynamic playlist.. I have a WIP patch for it, that I may upload for consideration, but not sure it's ready for release.