[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Yoni Rabkin
Subject: Re: Recovering playback state of multiple playlists and over multiple sessions
Date: Wed, 20 Oct 2021 08:35:07 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

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

   "Cut your own wood and it will warm you twice"

reply via email to

[Prev in Thread] Current Thread [Next in Thread]