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

[roldengarm]

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

[photovoltex]

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

[roldengarm]

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

[photovoltex]

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?

[roldengarm]

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

Spotify.queue.issue.mp4

[photovoltex]

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]

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.