The first thing I thought is why stop. Why not move to the end of the current song and let it go to the next one its own.
Erica Sent from [Proton Mail](https://proton.me/mail/home) for Android. -------- Original Message -------- On Monday, 12/22/25 at 13:56 Fran Burstall (Gmail) <[email protected]> wrote: > 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.
