"Fran Burstall (Gmail)" <[email protected]> writes: > 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?
I can definitely have a look, but I'm travelling this year-end, so it might take me a bit to get to it. > ---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. >> >> -- "Cut your own wood and it will warm you twice"
