Yuchen Pei <[email protected]> writes: > Mike Kazantsev <[email protected]> writes: > >> On Tue, 19 Oct 2021 07:24:14 +0500 >> Mike Kazantsev <[email protected]> wrote: >> >>> On Tue, 19 Oct 2021 13:05:56 +1100 >>> Yuchen Pei <[email protected]> wrote: >>> > > 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. >> ... >>> 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. >> >> I've updated emms-player-mpv to handle this situation by updating >> emms-playing-time upon receiving mpv "playback-restart" events, >> which >> should follow seeks. >> >> As you can also pause/unpause playback via window controls or >> hotkeys, >> also added propagation of mpv "pause"/"unpause" events to emms >> playback >> pausing/unpausing too. >> >> This should hopefully address the situation where you've got 10h of >> playback on 45m video, presumably because emms was counting time >> while >> it was paused overnight or something like that. >> >> >> I've also simplified updates of current track duration via mpv's >> observe-property functionality, so that it'd push updates when >> necessary, instead of requesting these from emms at any point. >> >> >> These changes are implemented as recent 12f7d29 and ea6728d commits >> in >> emms git repo, which I guess you can grab from there to test: >> >> https://git.savannah.gnu.org/cgit/emms.git/ >> > > Aweseom thanks, it seems to be working well. > > Unrelated to the mpv player, but related to the topic of this thread, > how about we add a text property last-stopped-at to a track to record > the timestamp in the track when it was stopped / paused? We already > have a last-played property presumably recording when this track was > last palyed. > > With this we can add a facility to resume where the track was last > left over. It could be a function to resume a track, and > optionally be a custom variable about the behaviour of > emms-playlist-mode-play-smart. > > What do you think?
The trick with that is that last-played doesn't care about the backend, while last-stopped-at requires communication with the backend. I don't mind adding a last-stopped-at, but the feature needs to be aware of if it can reliably get that information, and not populate that field if it cannot. -- "Cut your own wood and it will warm you twice"
