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