The patch certainly solves the immediate problem but I wonder if this is
the right approach.
1. A similar patch will be needed for emms-librefm-scrobbler which makes
the same assumption that the current track when emms-stop is called is the
one that is actually playing.
2. I think this assumption is a reasonable one for devs to make when
targeting emms-player-stopped-hook and friends.
The alternative would be to make `emms-browser-add-tracks-and-play' play
nicer. I note the source of that function records some unease about how it
works:
(defun emms-browser-add-tracks-and-play ()
"Add all tracks at point, and play the first added track."
(interactive)
(let ((old-pos (emms-browser-add-tracks)))
(with-current-emms-playlist
(goto-char old-pos)
;; if we're sitting on a group name, move forward
(unless (emms-playlist-track-at (point))
(emms-playlist-next))
(emms-playlist-select (point)))
;; FIXME: is there a better way of doing this?
(emms-stop)
(emms-start)))
I do not understand this function well enough to try and improve it.
Does anyone else? Yoni?
---Fran
On Sun, 21 Dec 2025 at 01:43, Jake Coble <[email protected]> wrote:
> The function `emms-browser-add-tracks-and-play' switches tracks before
> invoking `emms-stop'. This causes the hooks in
> `emms-player-stopped-hook' to run after the current track has changed.
> This means that, when `emms-listenbrainz-scrobbler-stop-hook' is
> called, it submits the track we switched to, not the track that's
> playing.
>
> This patch fixes that by storing the relevant track instead of
> depending on the currently playing track.
>
>
