Re: Recovering playback state of multiple playlists and over multiple sessions

[Yoni Rabkin]

Mike Kazantsev <mk.fraggod@gmail.com> writes:

> On Wed, 20 Oct 2021 08:35:07 -0400
> Yoni Rabkin <yoni@rabkins.net> wrote:
>
>> > Unrelated to the mpv player, but related to the topic of this thread,
>> > how about we add a text property last-stopped-at to a track to record
>> > the timestamp in the track when it was stopped / paused?  We already
>> > have a last-played property presumably recording when this track was
>> > last palyed.
>> >
>> > With this we can add a facility to resume where the track was last
>> > left over.  It could be a function to resume a track, and 
>> > optionally be a custom variable about the behaviour of
>> > emms-playlist-mode-play-smart.
>> >
>> > What do you think?  
>> 
>> The trick with that is that last-played doesn't care about the backend,
>> while last-stopped-at requires communication with the backend. I don't
>> mind adding a last-stopped-at, but the feature needs to be aware of if
>> it can reliably get that information, and not populate that field if it
>> cannot.
>
> Maybe emms can just always store/update emms-playing-time on the track
> in playlist?
>
> That'd also double as "last stopped time" without adding any really new
> concepts, and there's 'info-playing-time for total duration there already.
>
>
> Otherwise implementation like this jumps to mind:
>
>   (funcall (emms-player-get emms-player-playing-p 'query-position))
>
> It's what mpv currently does in response to events, and presumably
> backends that only get it from somewhere periodically (e.g. stdout
> status line) can just cache it in some value.
>
> But if this is not implemented for backend, I'd think that fallback to
> emms-playing-time would seem reasonable, and then why not just always
> store that in the first place? :)

There is no reason not to do that; it wouldn't impact anything.

-- 
   "Cut your own wood and it will warm you twice"