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

[Mike Kazantsev]

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

> Yuchen Pei <hi@ypei.me> writes:
> 
> > Mike Kazantsev <mk.fraggod@gmail.com> writes:
> >  
> >> On Tue, 19 Oct 2021 12:22:38 +1100
> >> "" <hi@ypei.me> wrote:
> >>  
> >>> Mike Kazantsev <mk.fraggod@gmail.com> writes:  
> >>>  >
> >>> > "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)?  
> >>> >    
> >>> The seek was triggered by (emms-bookmark-next).  I saved a 
> >>> bookmark
> >>> in the middle of a track with (emms-bookmark-set) before 
> >>> switching to a different playlist, came back to the original
> >>> playlist, start the track from the beginning and invoked 
> >>> (emms-bookmark-next).  I can tell from the log and with
> >>> text-properties-at the seek timestamp is the same as the one 
> >>> saved in the bookmark.  Whether it saved the wrong timestamp, 
> >>> or
> >>> the seek did not work, I don't know.  The bookmark was at 
> >>> about 26 
> >>> minutes.  
> >>
> >> Oh, right, you have this seek sent in there:
> >>
> >>   ["seek",38214,"absolute"]
> >>
> >> While duration is reported to be:
> >>
> >>   {"command":["get_property","duration"],"request_id":651}
> >>   {"data":2729.433333,"request_id":651,"error":"success"} 
> >> I.e. 45-min file, and seek was sent to 38214 = ~10 hour mark,
> >> definitely beyond the end.
> >>
> >> Will check bookmarks specifically myself too, but if you see 
> >> that
> >> 38k
> >> value stored in the bookmark, I think it must be stored 
> >> incorrectly
> >> from somewhere, as pretty sure seek-to should just use amount 
> >> of
> >> seconds, and that doesn't seem to be that.  
> >
> >
> > emms-bookmarks-add uses the emms-playing-time, which from some
> > observatiosn seems totally different from the current timestamp 
> > in 
> > the track.
> >
> >  (emms-bookmarks-set (emms-playlist-current-selected-track) desc
> >  emms-playing-time))  
> 
> I think I might know the problem here... emms-playing-time seems 
> to be entirely controlled within emacs and not affected by what 
> happens in the player (mpv in my case).  If I seek in mpv the 
> emms-playing-time does not change at all.  Is there a way to pass 
> back the playing time from the player to emms to make 
> emms-playing-time or just emms-bookmark-add more accurate?

Oh, right, with videos you do have an actual mpv player window which
you control separately from emms.

Yeah, I think good way to do it might be to add a handler to either
"seek" or "playback-restart" event from mpv (gets issued after seeks)
to get current position there and set it as current playback time in emms.

In a custom code/config it can be done via emms-player-mpv-event-functions list.


There's also a common handler which emms-player-mpv uses
(emms-player-mpv-event-handler), which I think might be worth updating
to not re-fetch duration after seeks, but instead fetch/update playback
position in emms like that.

Will probably do that tomorrow.


-- 
Mike Kazantsev // fraggod.net