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? :)
signature.asc