Re: Recovering playback state of multiple playlists and over multiple sessions

[Yoni Rabkin]

Yuchen Pei <hi@ypei.me> writes:

> Mike Kazantsev <mk.fraggod@gmail.com> writes:
>
>> On Tue, 19 Oct 2021 07:24:14 +0500
>> Mike Kazantsev <mk.fraggod@gmail.com> wrote:
>>
>>> On Tue, 19 Oct 2021 13:05:56 +1100
>>> Yuchen Pei <hi@ypei.me> 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"