Yuchen Pei <[email protected]> writes: > Yoni Rabkin <[email protected]> writes: > >> Mike Kazantsev <[email protected]> writes: >> >>> On Wed, 20 Oct 2021 08:35:07 -0400 >>> Yoni Rabkin <[email protected]> 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"
