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? :) -- Mike Kazantsev // fraggod.net
