Mike Kazantsev <[email protected]> writes:
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 incorrectlyfrom 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)) --
Best,
Yuchen
PGP Key: 47F9 D050 1E11 8879 9040 4941 2126 7E93 EF86 DFD0
<https://ypei.me/assets/ypei-pubkey.txt>
signature.asc
Description: PGP signature
