librespot icon indicating copy to clipboard operation
librespot copied to clipboard

Reordering songs in the queue causes them to appear duplicated or in a different order

Open roldengarm opened this issue 1 year ago • 21 comments

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

roldengarm avatar Feb 10 '25 19:02 roldengarm

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

photovoltex avatar Feb 10 '25 19:02 photovoltex

@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?

roldengarm avatar Feb 10 '25 20:02 roldengarm

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?

photovoltex avatar Feb 10 '25 20:02 photovoltex

@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

roldengarm avatar Feb 10 '25 20:02 roldengarm

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

photovoltex avatar Feb 10 '25 20:02 photovoltex

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.

photovoltex avatar Feb 10 '25 21:02 photovoltex

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

bitclick avatar Mar 10 '25 18:03 bitclick

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

roldengarm avatar Apr 13 '25 02:04 roldengarm

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.

photovoltex avatar Apr 13 '25 07:04 photovoltex

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

dflvunoooooo avatar Apr 13 '25 14:04 dflvunoooooo

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 :)

photovoltex avatar Apr 13 '25 16:04 photovoltex

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

photovoltex avatar Apr 13 '25 16:04 photovoltex

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

bitclick avatar Apr 14 '25 18:04 bitclick

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)?

photovoltex avatar Apr 15 '25 17:04 photovoltex

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.

photovoltex avatar Apr 15 '25 18:04 photovoltex

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

bitclick avatar Apr 15 '25 19:04 bitclick

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.

dflvunoooooo avatar Apr 16 '25 21:04 dflvunoooooo

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

photovoltex avatar Apr 17 '25 05:04 photovoltex

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.

dflvunoooooo avatar Apr 17 '25 06:04 dflvunoooooo

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

bitclick avatar Apr 17 '25 07:04 bitclick

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

dflvunoooooo avatar Apr 17 '25 07:04 dflvunoooooo