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.
signature.asc