mirror of
https://github.com/devgianlu/go-librespot.git
synced 2026-04-26 05:15:49 +03:00
[GH-ISSUE #73] Reordering of queue has unexpected behaviours #56
Labels
No labels
bug
enhancement
pull-request
spotify-side
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/go-librespot#56
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @devgianlu on GitHub (Aug 21, 2024).
Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/73
Android: reordering tracks will duplicate the track being moved
iPhone: https://community.volumio.com/t/new-2023-spotify-plugin/63381/362
@aykevl commented on GitHub (Oct 4, 2024):
I debugged this a bit.
The issue appears to be that added tracks need an uid to make things like reordering work correctly. Adding an uid fixes this.
Spotify apps add a uid in the form of
q0,q1,q2, etc.Interestingly a similar bug is present when transferring between the Android app and open.spotify.com, or between different instances of open.spotify.com: if you add a few songs to the queue, then transfer to a different device, and then add some more songs, the queue now has multiple queued tracks of the same uid because the new device started counting from 0 again. That will really mess up the queue when you try to reorder these songs.
This is clearly a Spotify bug though. I'd say we can do better :)
(Maybe it's only a bug in open.spotify.com? I haven't tried transferring between native apps yet).
@aykevl commented on GitHub (Oct 4, 2024):
The same issue is present when transferring from Spotify Android to the desktop app (on MacOS). The UIDs start counting again from 0, and reordering the queue messes up the whole queue. So this issue seems really widespread among Spotify apps.
@devgianlu commented on GitHub (Oct 4, 2024):
I wonder if this is somehow related to #54
@aykevl commented on GitHub (Oct 4, 2024):
Yeah I was thinking the same. We can fix this bug and see if that helps.
I'll probably send a PR tomorrow.
@justinerickson commented on GitHub (Oct 4, 2024):
Interesting, is there an easy way to see the UIDs assigned?
I'm particularly curious to see if I can check how they look when playing on Echo/Alexa or Google Home as so far they seem to be stable with multiple devices adding to the same Spotify Jam and reordering the play queue. Though unsure if I'm getting lucky or they're doing something different. I am using Spotify MacOS and iPhone mostly but also didn't see issue with a quick test with open.spotify.com (but was just a quick test). Btw in case helpful Spotify Jam seemed to work well prior to the new plug-in (ie with volspotconnect2) though unsure if Spotify API changed since then.
Let me know if there is anything I can help capture/test to diagnose and/or see if the new PR tomorrow runs into other issues.
@aykevl commented on GitHub (Oct 5, 2024):
The way I did it is by opening Developer Tools (Firefox) of open.spotify.com, and in the network tab filtering for WebSocket connections (you will need to reload the page for it to become visible). If you select the one WebSocket connection and go to the Response tab, you can see all the messages exchanged. One of the more frequent messages you see is a cluster update, which contains
payloads[0].cluster.player_state.next_tracks.The same probably also works in Chrome.
Note that the API is different between the desktop app and open.spotify.com, but the player state appears to be the same data structure.
I would be very curious about that!
I'm not using Spotify Jam, just normal "connect to a different device". I guess Spotify Jam might work differently?
@aykevl commented on GitHub (Oct 5, 2024):
Fixed here: https://github.com/devgianlu/go-librespot/pull/114
By the way, to reproduce the reordering issue among official Spotify apps (controlled from Spotify Android):
You may have to do the last step more than once to see the bug. The bug is that after a reorder, both tracks in the queue are now the same (in fact, if you select one, the other will be selected as well at the same time).
@justinerickson commented on GitHub (Oct 5, 2024):
I tried combos of adding songs, reordering, finishing songs to dequeue, across Spotify MacOS, Spotify iOS, and open.spotify.com playing on my Echo Dot. It is able to successfully keep monotonically increasing the UID.
It is able to do so even when I reorder such that we dequeue the highest uid (as well as finish playing the previously dequeued highest uid. I'm unsure where it preserves the highest uid as I don't see it anywhere in the payloads JSON. I can see that Spotify is keeping my Recently Played songs in the Spotify MacOS app though
Here is my specific set of steps (and checks I did to confirm it works with Echo Dot). I also attached the final state of next_tracks JSON values
next_tracks_json.txt
Steps taken
uids to device mapping
Just added songs prior to shuffling
q0 = Spotify MacOS
q1 = Spotify iOS
q2 = Spotify iOS
q3 = open.spotify.com
a4 = Spotify MacOS
q5 = open.spotify.com
q6 = open.spotify.com
Added after shuffling
q7 = Spotify MacOS
q8 = Spotify iOS
q9 = open.spotify.com
After song finishes & q3 becomes current song
q10 = Spotify MacOS
q11 = open.spotify.com
q12 = Spotify iOS
After making the highest number song finish playing (not just dequeue)
q13 = Spotify MacOS
q14 = Spotify iOS
q15 = open.spotify.com
@justinerickson commented on GitHub (Oct 5, 2024):
Ahh I missed where you said switch to a different device for playing after reordering, above was all on same playing device. I do see the bug where Spotify resets uid to "q0" after each playing device switch.
Here is what I see when I switch devices (between Echo Dot, Google Home, and Spotify MacOS):
Attached is next_tracks JSON after switching between devices a few times and adding songs in between. Then reodering and playing one of the uid:"q0" songs.
next_tracks_swapdevices_json.txt
Seems like each device ideally would set the next uid to the max uid of the next_tracks objects (possibly max of next_tracks uid's + current song uid) instead of resetting to q0. Just saw your PR already does this with next_track uids. Doesn't seem like there is much value in doing max of next_tracks + current song uid since going back oddly does not re-enqueue the current track
Note: The bug I was seeing with Volumio that reordering from multiple devices was causing items to disappear even when playing on the single Volumio device the entire time.
@aykevl commented on GitHub (Oct 5, 2024):
@justinerickson thank you for the in-depth testing! Then it really looks like a Spotify bug here, that we can only work around.
One other option would be to assign random UIDs, I tried this and it works but figured that keeping the pattern of q0, q1, etc might be better for compatibility.
@justinerickson commented on GitHub (Oct 5, 2024):
No problem and agreed your PR looks like the best workaround for swapping playing devices.
For the original issue where attempting to reorder songs that were added to a Volumio queue (without changing playing device) was causing them to disappear is a symptom of not setting "uid"? If so, this hopefully that fixes the other issues I was seeing with the queue disappearing periodically when trying to use multiple Spotify apps to add songs to the same Volumio playing device queue.
@justinerickson commented on GitHub (Oct 21, 2024):
FYI I manually updated my setup with this fix and from initial testing so far seems to fix all the multi-user Spotify Jams/enqueuing issues. Will post if any new surprises. Thanks for the fix (and pointers on how to inspect the Spotify payloads)!!!
@pachulo commented on GitHub (Feb 2, 2025):
Hi!
I am still experiencing weird behaviour when reordering tracks on the queue from the Android's Spotify app: it seems like the changes of order are ignored.Sorry, the queue works OK; I'm experiencing weird behaviour when reordering tracks from the "Next From:". Those changes are ignored when listening through go-librespot.
Thanks for all the work involved!