[GH-ISSUE #1464] Reordering songs in the queue causes them to appear duplicated or in a different order #658

Open
opened 2026-02-27 19:31:48 +03:00 by kerem · 21 comments
Owner

Originally created by @roldengarm on GitHub (Feb 10, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1464

Description

I'm using the Android Spotify app and have songs in my queue. When I go to the queue and drag a song to a different location in the queue, it puts it in a different location than where I moved it to and sometimes it duplicates the song.

Version

What version(s) of librespot does this problem exist in?

I'm not very familiar with cargo. I've installed it on 15 December 14:19 NZT

How to reproduce

  1. librespot -n "Librespot Speaker" -b 160
  2. Add a playlist or album to the queue in the Android app
  3. Select the Librespot Speaker
  4. Open the queue and move a song to a different location in the queue
  5. Notice the queue order changes and possibly duplicates the song

Log

Sorry, it was too long for both here and in Pastebin unfortunately. See this file:

librespot.log

Host (what you are running librespot on):

  • OS: Linux
  • Platform: HP Server
Originally created by @roldengarm on GitHub (Feb 10, 2025). Original GitHub issue: https://github.com/librespot-org/librespot/issues/1464 ### Description I'm using the Android Spotify app and have songs in my queue. When I go to the queue and drag a song to a different location in the queue, it puts it in a different location than where I moved it to and sometimes it duplicates the song. ### Version What version(s) of *librespot* does this problem exist in? I'm not very familiar with cargo. I've installed it on 15 December 14:19 NZT ### How to reproduce 1. `librespot -n "Librespot Speaker" -b 160 ` 2. Add a playlist or album to the queue in the Android app 3. Select the Librespot Speaker 4. Open the queue and move a song to a different location in the queue 5. Notice the queue order changes and possibly duplicates the song ### Log Sorry, it was too long for both here and in Pastebin unfortunately. See this file: [librespot.log](https://github.com/user-attachments/files/18740027/librespot.log) ### Host (what you are running `librespot` on): - OS: Linux - Platform: HP Server
Author
Owner

@photovoltex commented on GitHub (Feb 10, 2025):

To get the version you are using run the following command, but as you just installed it via cargo it should probably be 0.6.0.

librespot --version

The issue sounds similar to #861. And should be fixed on the dev branch as the whole logic around the queue was reworked to support the dealer and fix various issues around it.

One way to install the latest version is via cargo itself.

cargo install --git https://github.com/librespot-org/librespot
<!-- gh-comment-id:2649105039 --> @photovoltex commented on GitHub (Feb 10, 2025): To get the version you are using run the following command, but as you just installed it via cargo it should probably be `0.6.0`. ```sh librespot --version ``` The issue sounds similar to #861. And should be fixed on the dev branch as the whole logic around the queue was reworked to support the dealer and fix various issues around it. One way to install the latest version is via cargo itself. ```sh cargo install --git https://github.com/librespot-org/librespot ```
Author
Owner

@roldengarm commented on GitHub (Feb 10, 2025):

@photovoltex Thank you for your response!

I've just installed the latest dev version. It seems to be fine now when queuing items after connecting to Librespot (it does refresh the UI briefly though, I guess that's expected). Unfortunately it still reorders songs inadvertently if I connect to Librespot AFTER setting up a queue, i.e. with an existing queue.

Would you like me to upload a log as well?

<!-- gh-comment-id:2649142151 --> @roldengarm commented on GitHub (Feb 10, 2025): @photovoltex Thank you for your response! I've just installed the latest dev version. It seems to be fine now when queuing items after connecting to Librespot (it does refresh the UI briefly though, I guess that's expected). Unfortunately it still reorders songs inadvertently if I connect to Librespot AFTER setting up a queue, i.e. with an existing queue. Would you like me to upload a log as well?
Author
Owner

@photovoltex commented on GitHub (Feb 10, 2025):

I don't think a log will help all to much, as you can usually reproduce it pretty well if we have enough information how to. As it seems to be related to transferring the log wouldn't even be helpful as the transfer data is send base64 encoded and the decoded object isn't printed to the log.

Anyhow, could you explain the issue at a short example maybe? The following questions might help to provide all the required info to reproduce the issue consistently^^

  • What did you do before connecting?
  • What did it look like right before transferring?
  • What did it look like after the transfer?
  • Did you have any options (shuffle or any repeat) enabled?
  • And what exactly are you referring as the queue?
    • The "Next from" items, or the entire queue?
<!-- gh-comment-id:2649166470 --> @photovoltex commented on GitHub (Feb 10, 2025): I don't think a log will help all to much, as you can usually reproduce it pretty well if we have enough information how to. As it seems to be related to transferring the log wouldn't even be helpful as the transfer data is send base64 encoded and the decoded object isn't printed to the log. Anyhow, could you explain the issue at a short example maybe? The following questions might help to provide all the required info to reproduce the issue consistently^^ - What did you do before connecting? - What did it look like right before transferring? - What did it look like after the transfer? - Did you have any options (shuffle or any repeat) enabled? - And what exactly are you referring as the queue? - The "Next from" items, or the entire queue?
Author
Owner

@roldengarm commented on GitHub (Feb 10, 2025):

@photovoltex I've created a screen recording that should answer your questions and shows the issue

https://github.com/user-attachments/assets/87f9df9f-731c-49b3-b8e3-601b8d626a94

<!-- gh-comment-id:2649220921 --> @roldengarm commented on GitHub (Feb 10, 2025): @photovoltex I've created a screen recording that should answer your questions and shows the issue https://github.com/user-attachments/assets/87f9df9f-731c-49b3-b8e3-601b8d626a94
Author
Owner

@photovoltex commented on GitHub (Feb 10, 2025):

Thanks for the recording :)

From a quick test to reproduce it. It seems like the actual queued items are transferred correctly. But changes in the context seem to be missing? OHHH... well... yeah that make sense xD

Eh, short breakdown how we transfer:

  • we find the currently playing track and play it
    • so that we can make the transition smooth (sound vise)
  • in the background the context is resolved
  • when we have our context we add the queue and the context to create our "next tracks"
    • the queue is transferred separately (so it's completely separate from the context, which makes the transfer very easy)

Soo yeah... the behavior make sense, as we currently fully ignore the changes in the context or rather resolve the context from scratch instead of taking the hint provided by the transfer request.

I think if I remember correctly the transferred data contain items of the context, but only a few... It might be that these items are used to communicate the reordered items. Anyhow good find :D

<!-- gh-comment-id:2649222300 --> @photovoltex commented on GitHub (Feb 10, 2025): > Thanks for the recording :) From a quick test to reproduce it. It seems like the actual queued items are transferred correctly. But changes in the context seem to be missing? OHHH... well... yeah that make sense xD Eh, short breakdown how we transfer: - we find the currently playing track and play it - so that we can make the transition smooth (sound vise) - in the background the context is resolved - when we have our context we add the queue and the context to create our "next tracks" - the queue is transferred separately (so it's completely separate from the context, which makes the transfer very easy) Soo yeah... the behavior make sense, as we currently fully ignore the changes in the context or rather resolve the context from scratch instead of taking the hint provided by the transfer request. I think if I remember correctly the transferred data contain items of the context, but only a few... It might be that these items are used to communicate the reordered items. Anyhow good find :D
Author
Owner

@photovoltex commented on GitHub (Feb 10, 2025):

Huh... interesting behavior shown by the recording, that's not at all what I expected, thanks for recording^^. Will take a deeper look into it later. Might be also related to some missing transfer related logic as explained above.

<!-- gh-comment-id:2649228922 --> @photovoltex commented on GitHub (Feb 10, 2025): Huh... interesting behavior shown by the recording, that's not at all what I expected, thanks for recording^^. Will take a deeper look into it later. Might be also related to some missing transfer related logic as explained above.
Author
Owner

@bitclick commented on GitHub (Mar 10, 2025):

i think i am affected too.. trying to move a song in the queue duplicates it. also v0.6

<!-- gh-comment-id:2711485417 --> @bitclick commented on GitHub (Mar 10, 2025): i think i am affected too.. trying to move a song in the queue duplicates it. also v0.6
Author
Owner

@roldengarm commented on GitHub (Apr 13, 2025):

@photovoltex did you have a chance to look into this please?

<!-- gh-comment-id:2799546779 --> @roldengarm commented on GitHub (Apr 13, 2025): @photovoltex did you have a chance to look into this please?
Author
Owner

@photovoltex commented on GitHub (Apr 13, 2025):

Not really yet. As this concerns their mobile clients it's also more guessing what might help to fix the issue. I will try to take a look later but can't promise anything. I'm theoretically quite optimistic tho, as the fix itself can't be too hard, it's probably more figuring out what the mobile client wants to receive.

<!-- gh-comment-id:2799840166 --> @photovoltex commented on GitHub (Apr 13, 2025): Not really yet. As this concerns their mobile clients it's also more guessing what might help to fix the issue. I will try to take a look later but can't promise anything. I'm theoretically quite optimistic tho, as the fix itself can't be too hard, it's probably more figuring out what the mobile client wants to receive.
Author
Owner

@dflvunoooooo commented on GitHub (Apr 13, 2025):

I am also affected. librespot 0.6.0 383a6f69 (Built on 2025-04-13, Build ID: 1744553744, Profile: release)

<!-- gh-comment-id:2799973912 --> @dflvunoooooo commented on GitHub (Apr 13, 2025): I am also affected. `librespot 0.6.0 383a6f69 (Built on 2025-04-13, Build ID: 1744553744, Profile: release) `
Author
Owner

@photovoltex commented on GitHub (Apr 13, 2025):

For all v0.6 users, this issue doesn't exist anymore in the initially described state, see the previous https://github.com/librespot-org/librespot/issues/1464#issuecomment-2649142151. I will look into the other issue describe by @roldengarm, but please follow and read the whole issue discussion to see where the current state of things are before commenting that it happens in the old version :)

<!-- gh-comment-id:2800016666 --> @photovoltex commented on GitHub (Apr 13, 2025): For all v0.6 users, this issue doesn't exist anymore in the initially described state, see the previous https://github.com/librespot-org/librespot/issues/1464#issuecomment-2649142151. I will look into the other issue describe by @roldengarm, but please follow and read the whole issue discussion to see where the current state of things are before commenting that it happens in the old version :)
Author
Owner

@photovoltex commented on GitHub (Apr 13, 2025):

Just tried to reproduce the issue shown. And I currently can't reproduce it. I tried the following with the android app:

  1. start short playlist (4 tracks)
  2. stop playback
  3. add another short playlist (4 tracks)
  4. switch to librespot
  5. reorder tracks from the queued playlist
  6. seems to work

looks a lot wonky with the new ui, but generally seems to update the positions correctly

Then I noticed that in your clip you were already in a queued context. So did the same as before, but added two steps in between 1. and 2.

  • I added a single track to the queue
  • and skipped to it
  • which also seems to work

So if anyone has another idea what could cause the issue shown in this video (https://github.com/librespot-org/librespot/issues/1464#issuecomment-2649220921) let me know :D

But if this was just a fluke then the issue itself should be resolve with the up-coming version

<!-- gh-comment-id:2800026097 --> @photovoltex commented on GitHub (Apr 13, 2025): Just tried to reproduce the issue shown. And I currently can't reproduce it. I tried the following with the android app: 1. start short playlist (4 tracks) 2. stop playback 3. add another short playlist (4 tracks) 4. switch to librespot 5. reorder tracks from the queued playlist 6. seems to work > looks a lot wonky with the new ui, but generally seems to update the positions correctly Then I noticed that in your clip you were already in a queued context. So did the same as before, but added two steps in between 1. and 2. - I added a single track to the queue - and skipped to it - which also seems to work So if anyone has another idea what could cause the issue shown in this video (https://github.com/librespot-org/librespot/issues/1464#issuecomment-2649220921) let me know :D But if this was just a fluke then the issue itself should be resolve with the up-coming version
Author
Owner

@bitclick commented on GitHub (Apr 14, 2025):

i think i am affected too.. trying to move a song in the queue duplicates it. also v0.6

I can reproduce it on the android client playing via librespot

expected functionality

  1. play a song and queue a bunch of other songs
  2. move a song in the queue to first place so it would play next
  3. the song gets removed from its old place and is put in front of the list, bumping all other songs back one place

actual (faulty?) functionality

  1. play a song and queue a bunch of other songs

  2. move a song (1) in the queue to first place (2) so it would play next

    screenshot step 2

    Image

  3. the song gets duplicated (this happens over the span of a few seconds. the gui changes without user interaction).

  4. it is still at the original position (1) and at the new position (2). the original song at (2) is removed from the queue

    screenshot step 4

    Image

<!-- gh-comment-id:2802629843 --> @bitclick commented on GitHub (Apr 14, 2025): > i think i am affected too.. trying to move a song in the queue duplicates it. also v0.6 I can reproduce it on the android client playing via librespot # expected functionality 1. play a song and queue a bunch of other songs 2. move a song in the queue to first place so it would play next 3. the song gets removed from its old place and is put in front of the list, bumping all other songs back one place # actual (faulty?) functionality 1. play a song and queue a bunch of other songs 2. move a song (_1_) in the queue to first place (_2_) so it would play next <details> <summary>screenshot step 2</summary> ![Image](https://github.com/user-attachments/assets/609bfc0b-5753-403a-a37e-706d0153b978) </details> 3. the song **gets duplicated** (this happens over the span of a few seconds. the gui changes without user interaction). 4. it is still at the original position (_1_) and at the new position (_2_). the **original song at (_2_) is removed** from the queue <details> <summary>screenshot step 4</summary> ![Image](https://github.com/user-attachments/assets/c5f85edd-a314-4db0-85b6-bcbf4516e2d9) </details>
Author
Owner

@photovoltex commented on GitHub (Apr 15, 2025):

Will take a look later with these steps. But just to be sure which version did you use? 0.6.0 (the release version) or 0.6.0-dev (the current latest version, in which this should behave differently)?

<!-- gh-comment-id:2806985517 --> @photovoltex commented on GitHub (Apr 15, 2025): Will take a look later with these steps. But just to be sure which version did you use? 0.6.0 (the release version) or 0.6.0-dev (the current latest version, in which this should behave differently)?
Author
Owner

@photovoltex commented on GitHub (Apr 15, 2025):

So, just checked it on version librespot 0.6.0-dev 59381cc (latest dev at the time) with your described steps and it seems to work just fine.

<!-- gh-comment-id:2807185928 --> @photovoltex commented on GitHub (Apr 15, 2025): So, just checked it on version `librespot 0.6.0-dev 59381cc` (latest dev at the time) with your described steps and it seems to work just fine.
Author
Owner

@bitclick commented on GitHub (Apr 15, 2025):

good point.. i am using
librespot 0.6.0 383a6f6 (Built on 2024-11-03, Build ID: 4Ye8E7iN, Profile: release)
so this is the latest release version. (sorry i missed your comment on that https://github.com/librespot-org/librespot/issues/1464#issuecomment-2649105039)

i will try to test 59381cc in the next days and report back

<!-- gh-comment-id:2807271869 --> @bitclick commented on GitHub (Apr 15, 2025): good point.. i am using `librespot 0.6.0 383a6f6 (Built on 2024-11-03, Build ID: 4Ye8E7iN, Profile: release)` so this is the latest release version. (sorry i missed your comment on that https://github.com/librespot-org/librespot/issues/1464#issuecomment-2649105039) i will try to test `59381cc` in the next days and report back
Author
Owner

@dflvunoooooo commented on GitHub (Apr 16, 2025):

So, just checked it on version librespot 0.6.0-dev 59381cc (latest dev at the time) with your described steps and it seems to work just fine.

Seems to be resolved with 59381cc for me too.

<!-- gh-comment-id:2810825088 --> @dflvunoooooo commented on GitHub (Apr 16, 2025): > So, just checked it on version `librespot 0.6.0-dev 59381cc` (latest dev at the time) with your described steps and it seems to work just fine. Seems to be resolved with 59381cc for me too.
Author
Owner

@photovoltex commented on GitHub (Apr 17, 2025):

Good to know :)

Could you try and reproduce the issue that is shown in the clip here? From my testing, I couldn't reproduce the behavior, but maybe you might have more luck!
https://github.com/librespot-org/librespot/issues/1464#issuecomment-2649220921

<!-- gh-comment-id:2811852522 --> @photovoltex commented on GitHub (Apr 17, 2025): Good to know :) Could you try and reproduce the issue that is shown in the clip here? From my testing, I couldn't reproduce the behavior, but maybe you might have more luck! https://github.com/librespot-org/librespot/issues/1464#issuecomment-2649220921
Author
Owner

@dflvunoooooo commented on GitHub (Apr 17, 2025):

Yes with version 383a6f69 I had the problem, with moving an item from the queue it was duplicated and the original item was replaced. But there are two different queues. One get generated by spotify when playing a playlist or something like that and a different queue, when single songs have been added to the queue. I only had problems moving songs from the second form of queue.

<!-- gh-comment-id:2811888144 --> @dflvunoooooo commented on GitHub (Apr 17, 2025): Yes with version `383a6f69` I had the problem, with moving an item from the queue it was duplicated and the original item was replaced. But there are two different queues. One get generated by spotify when playing a playlist or something like that and a different queue, when single songs have been added to the queue. I only had problems moving songs from the second form of queue.
Author
Owner

@bitclick commented on GitHub (Apr 17, 2025):

Yes the playlist reordering ordering seems to work as expected with github.com/librespot-org/librespot@59381ccad3 but now i have problems transferring the playback to librespot.. it jumps right back to the android client most of the time..

will revert to the release-version for now

<!-- gh-comment-id:2812052525 --> @bitclick commented on GitHub (Apr 17, 2025): Yes the playlist reordering ordering seems to work as expected with https://github.com/librespot-org/librespot/commit/59381ccad38ed39037392f3d2d30bf0d9593ff56 but now i have problems transferring the playback to librespot.. it jumps right back to the android client most of the time.. will revert to the release-version for now
Author
Owner

@dflvunoooooo commented on GitHub (Apr 17, 2025):

I have no such problems, works like a charm now.

<!-- gh-comment-id:2812091330 --> @dflvunoooooo commented on GitHub (Apr 17, 2025): I have no such problems, works like a charm now.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/librespot#658
No description provided.