Possible to add position in playlist to resume feature?

[yawfle]

The resume feature is nice, but I think it's usefullness could be enhanced if the resume information also included playlist position, if that's the mode that cmus was in at quit. As it is now, when cmus starts up in the playlist view/mode and resumes playing the file, there's no indication of the current track in the playlist, and after playing the file, the playlist is started playing from the beginning. Any chance this functionality could be added?

[Gregory Petrosyan]

Post by yawfle
The resume feature is nice, but I think it's usefullness could be enhanced if
the resume information also included playlist position, if that's the mode
that cmus was in at quit. As it is now, when cmus starts up in the playlist
view/mode and resumes playing the file, there's no indication of the current
track in the playlist, and after playing the file, the playlist is started
playing from the beginning. Any chance this functionality could be added?

Just wanted to thank you for the feature request — I'll try to look into it when
I'll have some time.

Gregory

[Johannes Weißl]

Hi yawfle,

Post by yawfle
The resume feature is nice, but I think it's usefullness could be
enhanced if the resume information also included playlist position, if
that's the mode that cmus was in at quit. As it is now, when cmus
starts up in the playlist view/mode and resumes playing the file,
there's no indication of the current track in the playlist, and after
playing the file, the playlist is started playing from the beginning.
Any chance this functionality could be added?

I've just now written a "working-but-too-ugly-to-send" patch that
implements this functionality. The problem is that the resume
information is loaded before the library/playlist is read, which is a
good thing, because loading those could take minutes. The problem is,
cmus can't jump to a specific row if no row is there (because no tracks
have been loaded yet).

So my patch assumes loading is very fast and tries to jump to the
correct row after 1/4 second, which works if the library/playlist is
small and cached. The correct approach would maybe be something like a
hook (callback) in the playlist/library loading, but this is more
complicated, so I have to postpone it to later.

It would be cool if you would add it to the roadmap [1] so we don't
forget about it! Also, I've attached the (non-fit for inclusion) patch.

Johannes

[1] http://cmus.sourceforge.net/wiki/doku.php?id=todo

[yawfle]

The problem is that the resume information is loaded before the
library/playlist is read, which is a good thing, because loading those
could take minutes. The problem is, cmus can't jump to a specific row
if no row is there (because no tracks have been loaded yet).

I see what you mean... I wonder if there's any way to store the (current|last played) playlist index in the playlist itself, independent of the resume data, perhaps? Or, upon loading the playlist (or at least if playback is in playlist mode), check if the currently playing/last played track is a member of the list, and make it current track in that mode/view? I'm sorry if that doesn't make sense, I've had a lot of beer tonight... :)

[so many beers that I sent my first reply from an address that the list didn't recognize... sorry if this shows up twice...]

[Johannes Weißl]

Hi,

Post by yawfle

The problem is that the resume information is loaded before the
library/playlist is read, which is a good thing, because loading those
could take minutes. The problem is, cmus can't jump to a specific row
if no row is there (because no tracks have been loaded yet).

I see what you mean... I wonder if there's any way to store the
(current|last played) playlist index in the playlist itself,
independent of the resume data, perhaps? Or, upon loading the playlist
(or at least if playback is in playlist mode), check if the currently
playing/last played track is a member of the list, and make it current
track in that mode/view? I'm sorry if that doesn't make sense, I've
had a lot of beer tonight... :)

It does make perfect sense! The problem is, our playlist format is "one
line per track", and it would be pretty big change to turn it into a
structured (non-standard) format just for that. But we could maybe hand
over the current track to the playlist-loading function (from the resume
data), instead of a hook afterwards. I have to look into it!

Post by yawfle
[so many beers that I sent my first reply from an address that the
list didn't recognize... sorry if this shows up twice...]

No harm done :-)


Johannes

[yawfle]

Post by Johannes Weißl
It does make perfect sense! The problem is, our playlist format is "one
line per track", and it would be pretty big change to turn it into a
structured (non-standard) format just for that. But we could maybe hand
over the current track to the playlist-loading function (from the resume
data), instead of a hook afterwards. I have to look into it!

It seems like it could be as simple as a comment line at the head of the playlist file, containing an index within the file? This would have the benefit of being able to save multiple playlists each with it's own "bookmark"... not sure if this would be considered a "structured (non-standard)" format, but might collide with the "#EXTM3U" convention, I guess... It's probably time for me to look deeper into this stuff myself instead of just asking dumb questions. :)