On Tue, 19 Oct 2021 13:05:56 +1100 Yuchen Pei <[email protected]> wrote: > Yuchen Pei <[email protected]> writes: > > > 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 > >> incorrectly > >> from 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)) > > I think I might know the problem here... emms-playing-time seems > to be entirely controlled within emacs and not affected by what > happens in the player (mpv in my case). If I seek in mpv the > emms-playing-time does not change at all. Is there a way to pass > back the playing time from the player to emms to make > emms-playing-time or just emms-bookmark-add more accurate?
Oh, right, with videos you do have an actual mpv player window which you control separately from emms. Yeah, I think good way to do it might be to add a handler to either "seek" or "playback-restart" event from mpv (gets issued after seeks) to get current position there and set it as current playback time in emms. In a custom code/config it can be done via emms-player-mpv-event-functions list. There's also a common handler which emms-player-mpv uses (emms-player-mpv-event-handler), which I think might be worth updating to not re-fetch duration after seeks, but instead fetch/update playback position in emms like that. Will probably do that tomorrow. -- Mike Kazantsev // fraggod.net
