emms-help
[Top][All Lists]
Advanced

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

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


From: Mike Kazantsev
Subject: Re: Recovering playback state of multiple playlists and over multiple sessions
Date: Tue, 19 Oct 2021 05:01:28 +0500

On Tue, 19 Oct 2021 09:13:31 +1100
Yuchen Pei <hi@ypei.me> wrote:

> > If mpv player is used, I'd also suspect that immediately 
> > restoring
> > position might not work due to race with async playback start - 
> > e.g.
> > "seek" command being sent before playback actually starts in mpv 
> > or
> > something like that.
> >
> > Don't think I've tested restoring bookmarks myself, but if it 
> > doesn't
> > look like tagging issue of some kind, maybe try doing this 
> > before
> > starting playback/bookmark-restore:
> >
> >   (setq emms-player-mpv-debug t)
> >
> > And then check *Messages* buffer to see whether:
> >
> >  - "seek" command is being sent to mpv at all.
> >  - Whether it precedes {"event": "playback-restart"} there.  
> 
> It does precede playback-restart.  I tried using 
> emms-bookmark-next when the track is playing or paused.  Both 
> times it sends the seek request and skip to the end of the track.
> 
> Here's when I paused the track first:
> 
...
> 
> Here's when I started playing the track first:
> 
...

Ah, right, it sends playback-restart event after seek as well.

Both outputs look normal to me though, and I think should skip to
specified position in the track (unless there's a problem doing that on
the mpv side or in the file/source).

"Both times it sends the seek request and skip to the end of the track"
above sounds to me a bit like an unexpected/undesirable result though -
is that seek position that you're using supposed to be "end of the
track", or do you try seeking to the middle of the track, but always
end up at the end (and then cycling to next track in playlist)?

Logs don't seem to show mpv switching files, and I get pretty much same
output here with absolute seeks, so guess it's the expected result.


(on an unrelated note, re-fetching track duration after playback-restart
on seek is likely unnecessary, and maybe should be patched to use less
common event(s), though might need to check which ones to pick for all
media types and mpv versions)


-- 
Mike Kazantsev // fraggod.net



reply via email to

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