Reordering the queue duplicates & overwrites songs

[fallingcats]

Description
Reordering a song to position X duplicates it and replaces song at posX instead of inserting and removing it from the original position.

I'm surprised I don't see other reports about this (hope this isn't a duplicate), this has been a 100% reproducible issue for at least a year now for me.

Tested with librespot 0.6 "upgrade_deps" pr #1317, results seem unchanged

To Reproduce
Using my android phone:

1. Queue three songs (let's call them 1 2 3)
2. Move the second one after the third (=> 1 3 2)
3. Queue replaces the first queued song with the song that was dragged, the other songs sometimes stay ordered or revert. (=> 2 2 3 or 2 3 2)

I recommend this playlist for testing :)

Expected behavior
The queue should behave like it does when not connected to a spotifyd device, and just accept the new ordering.

Logs

Click to show logs

Jan 16 12:10:57 livingroomaudio spotifyd[12118]: received packet from [fe80::5839:794d:5ab8:dba9%2]:5353
Jan 16 12:10:57 livingroomaudio spotifyd[12118]: received question: IN _spotify-connect._tcp.local
Jan 16 12:10:57 livingroomaudio spotifyd[12118]: found interface Interface { name: "eth0", addr: V4(Ifv4Addr { ip: 10.0.4.7, netmask: 255.255.255.0, broadcast: Some(10.0.4.255) }) }
Jan 16 12:10:57 livingroomaudio spotifyd[12118]: found interface Interface { name: "eth0", addr: V6(Ifv6Addr { ip: 2001:871:25b:5153:eb19:c12b:a428:8d6f, netmask: ffff:ffff:ffff:ffff::, broadcast: None }) }
Jan 16 12:10:57 livingroomaudio spotifyd[12118]: sending packet to [ff02::fb]:5353
Jan 16 12:10:57 livingroomaudio spotifyd[12118]: received packet from 10.0.4.100:5353
Jan 16 12:10:57 livingroomaudio spotifyd[12118]: received question: IN _spotify-connect._tcp.local
Jan 16 12:10:57 livingroomaudio spotifyd[12118]: found interface Interface { name: "eth0", addr: V4(Ifv4Addr { ip: 10.0.4.7, netmask: 255.255.255.0, broadcast: Some(10.0.4.255) }) }
Jan 16 12:10:57 livingroomaudio spotifyd[12118]: found interface Interface { name: "eth0", addr: V6(Ifv6Addr { ip: 2001:871:25b:5153:eb19:c12b:a428:8d6f, netmask: ffff:ffff:ffff:ffff::, broadcast: None }) }
Jan 16 12:10:57 livingroomaudio spotifyd[12118]: sending packet to 224.0.0.251:5353
Jan 16 12:10:57 livingroomaudio spotifyd[12118]: received packet from [fe80::269:3ded:4de6:a860%2]:5353
Jan 16 12:10:57 livingroomaudio spotifyd[12118]: received packet from [fe80::269:3ded:4de6:a860%2]:5353 with no query
Jan 16 12:10:57 livingroomaudio spotifyd[12118]: received packet from 10.0.4.7:5353
Jan 16 12:10:57 livingroomaudio spotifyd[12118]: received packet from 10.0.4.7:5353 with no query
Jan 16 12:10:59 livingroomaudio spotifyd[12118]: kMessageTypeReplace "Pixel 6a" e61f26ec00d8cea64f6be656158fa42a4e511f43 1859072765 1737025841340 kPlayStatusPlay
Jan 16 12:10:59 livingroomaudio spotifyd[12118]: State: context_uri: "spotify:search:%23" index: 1 position_ms: 76167 status: kPlayStatusPlay position_measured_at: 1737025841327 context_description: "" shuffle: false repeat: false playing_from_fallback: true row: 0 playing_track_index: 1 track {gid: "\007\330\326~\253yM\311\2723y\233(\301V\244"} track {gid: "\007\330\326~\253yM\311\2723y\233(\301V\244" queued: true} track {gid: "\2500\323\n7+Jx\240<\020\244\242 \332\007" queued: true} track {gid: "\2500\323\n7+Jx\240<\020\244\242 \332\007" queued: true} track {gid: "\021O\265\310U\347D\022\215+\206i\013j\307," queued: true}
Jan 16 12:10:59 livingroomaudio spotifyd[12118]: Frame has 5 tracks
Jan 16 12:10:59 livingroomaudio spotifyd[12118]: Fetching autoplay context uri
Jan 16 12:10:59 livingroomaudio spotifyd[12118]: Sending status to server: [kPlayStatusPlay]
Jan 16 12:10:59 livingroomaudio spotifyd[12118]: command=SetAutoNormaliseAsAlbum(false)
Jan 16 12:10:59 livingroomaudio spotifyd[12118]: No autoplay_uri found
Jan 16 12:10:59 livingroomaudio spotifyd[12118]: AutoplayError: MercuryError

Compilation flags

• dbus_mpris
• dbus_keyring
• alsa_backend
• portaudio_backend
• pulseaudio_backend
• rodio_backend

Versions (please complete the following information):

• OS: Raspberry Pi OS Bookwork
• Spotifyd: v0.3.5 & eladyn:deps_upgrade
• cargo: 1.84.0 & 1.86.0-nightly
• current and past official Spotify client versions from the Play Store (other platforms/devices not tested)

[eladyn]

Oh, wow. I indeed didn't notice this up until now. Thank you for the report. Would you be able to see if this also happens with librespot on the dev branch? As far as I know, there have been some substantial changes regarding the queue / playing context recently.

Update: I just tested the current librespot and track re-ordering seems to be working very well there.

But if this also happens there, we should report it over there. Otherwise, we'll just have to wait for the next librespot release.

(And that is a great playlist for testing indeed. ^^)

[fallingcats]

As noted I did test librespot 0.6 and it has the exact same issue, in fact I wouldn't even have reported this if it was fixed for me in your branch :)

Edit: Or maybe I misunderstood and you mean librespot master instead of 0.6? I can't easily test that.

Edit2: Okay I think I got it now. librespot dev fixes the issue but the fix isn't yet released in librespot, and therefore not in the upgrades_deps branch either. I guess I'll have to wait a while longer then ....