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

[Mike Kazantsev]

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.


-- 
Mike Kazantsev // fraggod.net