[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Yoni Rabkin
Subject: Re: Recovering playback state of multiple playlists and over multiple sessions
Date: Thu, 21 Oct 2021 08:56:18 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

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"

reply via email to

[Prev in Thread] Current Thread [Next in Thread]