emms-help
[Top][All Lists]
Advanced

[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, 08 Dec 2021 17:51:19 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.90 (gnu/linux)

Apologies for taking so long to get to this. Busy times.

I have a number of comments:

First, the mode only really works with mpv at the moment. If I skip
around in VLC then it won't track to the skipped position. I would
suggest either making it support VLC as well, or blocking it from
working in anything but mpv with a friendly message (or a similar
communicative option). Otherwise, people who only use VLC (or another
player) will not understand why the feature is broken. If a feature only
works with certain backends, we need to be communicative with users of
the other backends.

Second, the use of `emms-playing-time-resume-from-last-played' is
non-standard. The user should expect that when they set
`emms-playing-time-resume-from-last-played' then it will start working,
and when they set it to nil then it will stop _immediately_. But in this
case the variable instead controls the insertion of a hook on loading
the mode. I think that the hook can be there all of the time, and a
variable such as `emms-playing-time-resume-p' will control if
`emms-playing-time-maybe-seek-to-last-played' is called at runtime. This
way a user can even change the value of `emms-playing-time-resume-p'
locally (as in a lamba/let).

Third, I was wondering if it makes sense to add two variables that can
optionally check if the track is within a set number of seconds from the
beginning or a set number of seconds from the end, and if so "snap" to
the beginning or end, respectively. This would prevent a situation when
someone stops a track a few seconds from the end, and then when they
play the track again it will just jump to those ending
seconds. Similarly, if a user starts a track and stops it a second or
two in because of an interruption, perhaps they would appreciate that it
"snaps" to the start instead of those two seconds or so in.

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



reply via email to

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