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. -- "Cut your own wood and it will warm you twice"
