mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #434] Wrong behaviour after finishing a playlist/album #279
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#279
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 @JPW21 on GitHub (Feb 15, 2020).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/434
Originally assigned to: @roderickvd on GitHub.
Official Spotify Clients jump to the first song in the playlist/album after playing the last one.
Librespot jumps 10 songs back when the playlist is over.
For example if the last song in an album is 26, librespot will jump to song number 16 when the last song is over.
If the album has 11 or less songs, it goes to the first, which is correct.
This issue would be minor, but this breaks looping any album/list longer than 11 songs.
@ashthespy commented on GitHub (Mar 13, 2020):
10 tracks seems quite serendipitous ;-)
But does this happen even for non dynamic playlists as well?
We have to revisit this again https://github.com/librespot-org/librespot/pull/305#pullrequestreview-214843475.
I would guess we need to either store the initial state's track_vec, and reset to that when we are done.
@JPW21 commented on GitHub (Aug 3, 2020):
What exactly do you mean with dynamic playlists?
I just tried it with the fresh compiled version and could reproduce it on my own custom playlist and on longer albums.
Here is the log after it happens (with repeat on, jumping back to track number 10 from 20 instead of starting at the beginning):
@roderickvd commented on GitHub (Sep 22, 2021):
Is this still the case? If I remember from testing #844 I believe it now does jump to the first track even on albums with more than 10 tracks. I think I had repeat disabled though.
@JPW21 commented on GitHub (Sep 22, 2021):
Yes still happening for me :(
Compiled from source today to make sure i have the newest version: librespot 0.2.0
57937a1(Built on 2021-09-22, Build ID: WZl0JoZA) alsa backendFor example it jumps from 27 to 17, even with repeat disabled.
@roderickvd commented on GitHub (Sep 22, 2021):
OK thanks for getting back so soon. I'll put it on my list.
@roderickvd commented on GitHub (Oct 5, 2021):
I just tried, but I can't reproduce this. Can you please post the full command line you are launching
librespotwith, as well as a full verbose log?@roderickvd commented on GitHub (Oct 5, 2021):
Never mind, have been able to reproduce it now!
@roderickvd commented on GitHub (Oct 5, 2021):
@JPW21 could you please try the fix at #859 and report back?
@edoiks commented on GitHub (Oct 12, 2021):
I tried #859 but still problem persist. when I have list with 20 elements but I start playback from the last song on the list, after end of the song next song is not the first but tenth from the end. However when I start from the first song on the list all the songs are played.
@roderickvd commented on GitHub (Oct 13, 2021):
Yes that’s the extent of this fix, only partly. Thanks for verifying. I’ll leave this issue open after merging that PR. The rest of it will require quite a bit more work.
@roderickvd commented on GitHub (Oct 13, 2021):
Re-opening as it's known that #859 is only a part fix.
@roderickvd commented on GitHub (Sep 30, 2022):
Reporting back after some time, this remains elusive.
spirconly sends 10 tracks happily saying that you're on position 10 even when you in fact started playback on 53 or whatever. Two things I can think of:Wait and see what happens when we get on the
dealer. Who knows it may give us more tracks, I don't know. @devgianlu can you chime in?From the
spircframe we know the context (e.g. the playlist or album). We could usemetadatato get the full track list ourselves, then establish the current position on that list by finding the active track gotten fromspirc.Depending on whether #1 will work we can decide to put development time on #2 or spend it on implementing the dealer (not for v0.5 though).
@devgianlu commented on GitHub (Oct 1, 2022):
I am very of out of the loop on Spotify stuff. It is possible that you need to fetch the entire playlist yourself, but I don't remember it being a problem with the "new API" (which is probably old too now).
@roderickvd commented on GitHub (Oct 1, 2022):
Thanks for the swift reply in spite of that. I remembered that we get to publish Spirc V3 (actually 3.2.6) support when we publish the device connect state over HTTPS. I will try and do so shortly, see if it will matter for this and a whole slew of other issues coming from these Spirc frame deficiencies.