mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #1097] First song is played twice when it should only be played once. #509
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#509
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 @LutzenH on GitHub (Jan 11, 2023).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1097
Hello everyone,
When transferring playback to a single track (TRACK_A) using the web-api and adding a track (TRACK_B) to the queue whilst TRACK_A is playing, You will notice that TRACK_A is played twice:
Behavior:
TRACK_A -> TRACK_B -> TRACK_AExpected behavior:
TRACK_A -> TRACK_BSteps to reproduce the behavior:
librespotwithlibrespot --backend pipe --device PIPE_NAME --bitrate 96 --name SPEAKER_NAME -c ./cache --username USERNAME --password PASSWORDSystem Info
commit 8941495b80d5927b270a1a8dafcfae3b77abb5a9Potential Fix
I managed to fix this by swapping these two lines of code:
github.com/librespot-org/librespot@8941495b80/connect/src/spirc.rs (L1281-L1282)In some situations
consume_queued_track()might remove a track from the list meaning that the amount of tracks is from that point actually lower than what is stored intracks_len.If you swap the two lines of code the
tracks_lenwill thus no longer in certain situations not be the same as the amount of tracks in the list. Which I think is more correct behavior than current behavior. (But I am not sure, as I am not that proficient in rust and this code base).@kingosticks commented on GitHub (Jan 11, 2023):
A debug log would be helpful
@LutzenH commented on GitHub (Jan 12, 2023):
Ok here is a debug log, I tried to remove all sensitive information (maybe a little to aggressive), If you see anything else; or need something more specific feel free to ask.
spotify:track:2oLjhx7w8Hyd3gry9cCXr7) using the transfer playback api-call.spotify:track:2xizRhme7pYeITbH1NLLGt) using the add to queue api-call.spotify:track:2oLjhx7w8Hyd3gry9cCXr7) starts playing again after Tchaikovsky: Swan Lake (spotify:track:2xizRhme7pYeITbH1NLLGt).@roderickvd commented on GitHub (Jan 14, 2023):
I think your proposed fix may be correct, but it must be tested in multiple variants. The code there is rather crufty. I admit that I spent some time there before, trying to fix some cases on the short-term, without doing the refactoring I suspect it might deserve on the long term.
Can you try your fix in varying combinations of repeat on/off, shuffle on/off, playlists with single/two/more tracks, and so on? There are quite a number of cases to cover here.
@photovoltex commented on GitHub (Jan 6, 2025):
Hey @LutzenH,
due to the dealer rework this part behaves quite differently. In fact it's currently broken (using the play api and providing just track-uris).
We will fix the missing implementation/handling for sure, but is there any reason why you would use the play endpoint with just track uris?
@LutzenH commented on GitHub (Jan 6, 2025):
@photovoltex At the time I needed something simple where I could start a song using the uri without running through a playlist or a queue; (the uri''s came from somewhere else and had to be played one by one). The software is no longer being worked on, so any changes would not bother me.
In the mean time since creating this issue; I have not kept up to date with any changes to librespot.
So feel free to close the issue!
@photovoltex commented on GitHub (Jan 7, 2025):
Hmm okay. Will keep it open for now as the issue isn't fixed, yet (as you can't even reproduce it currently). Thanks again for reporting, without it the missing support would have run under the radar :D