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

[Yoni Rabkin]

Yuchen Pei <hi@ypei.me> writes:

> Yoni Rabkin <yoni@rabkins.net> writes:
>
>> 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.
>
> Great.  Now the question is who is going to submit a patch for this?
> I can do it if you want.

Patches are always welcome here; we have an "open-door" policy to
welcome sojourning code.

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