Re: Patch: fix incorrect listenbrainz submissions

--000000000000a497be064689f4d2
Content-Type: text/plain; charset="UTF-8"

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.
>
>

--000000000000a497be064689f4d2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif">The patch certainly solves the immediate problem but I =
wonder if this is the right approach.</div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif">1.=C2=A0 A simil=
ar patch will be needed for emms-librefm-scrobbler which makes the same ass=
umption that the current track when emms-stop is called is the one that is =
actually playing.</div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif">2.=C2=A0 I think this assumption is a reasonable =
one for devs to make when targeting=C2=A0emms-player-stopped-hook and frien=
ds.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif"><br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif">The alternative would be to make `emms-browser-add=
-tracks-and-play&#39; play nicer.=C2=A0 I note the source of that function =
records some unease about how it works:</div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif"><br></div><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif">(defun emms-br=
owser-add-tracks-and-play ()<br>=C2=A0 &quot;Add all tracks at point, and p=
lay the first added track.&quot;<br>=C2=A0 (interactive)<br>=C2=A0 (let ((o=
ld-pos (emms-browser-add-tracks)))<br>=C2=A0 =C2=A0 (with-current-emms-play=
list<br>=C2=A0 =C2=A0 =C2=A0 (goto-char old-pos)<br>=C2=A0 =C2=A0 =C2=A0 ;;=
 if we&#39;re sitting on a group name, move forward<br>=C2=A0 =C2=A0 =C2=A0=
 (unless (emms-playlist-track-at (point))<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (e=
mms-playlist-next))<br>=C2=A0 =C2=A0 =C2=A0 (emms-playlist-select (point)))=
<br>=C2=A0 =C2=A0 ;; FIXME: is there a better way of doing this?<br>=C2=A0 =
=C2=A0 (emms-stop)<br>=C2=A0 =C2=A0 (emms-start)))<br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif"=
>I do not understand this function well enough to try and improve it.=C2=A0=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif">Does anyone else?=C2=A0 Yoni?</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif"><br></div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">--=
-Fran</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif"><br></div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif"><br></div></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Sun, 21 Dec 2025 at 01:43, Jake Cob=
le &lt;<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The =
function `emms-browser-add-tracks-and-play&#39; switches tracks before<br>
invoking `emms-stop&#39;. This causes the hooks in<br>
`emms-player-stopped-hook&#39; to run after the current track has changed.<=
br>
This means that, when `emms-listenbrainz-scrobbler-stop-hook&#39; is<br>
called, it submits the track we switched to, not the track that&#39;s<br>
playing.<br>
<br>
This patch fixes that by storing the relevant track instead of<br>
depending on the currently playing track.<br>
<br>
</blockquote></div>

--000000000000a497be064689f4d2--