On Tue, 19 Oct 2021 12:22:38 +1100 "" <[email protected]> wrote:
> Mike Kazantsev <[email protected]> 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
