mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #31] Shuffle buttons don't work on some clients. #20
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#20
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 @sashahilton00 on GitHub (Jan 29, 2018).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/31
Wednesday May 11, 2016 at 18:05 GMT
Originally opened as https://github.com/plietar/librespot/issues/82
When using librespot, I've noticed that I can't engage shuffle mode (or if it was previously engaged, I can't disengage it). This happens on Android clients, but not on the client on my Mac.
From the console on the machine running librespot, I see this:
This works:
These don't:
By "works" I should say that there is no feedback in the client. And it doesn't seem to "work" in that turning on shuffle in the android client doesn't show the state change in the Mac client.
It may also happen with the repeat feature.
This reminds me of a situation with a previous build, where the status of the player couldn't keep track of the time... when launching a client, it would start the playback time at 0:00, no matter what the actual playing was. Perhaps it's related? Something about parsing a heartbeat/status chunk?
Thanks
@sashahilton00 commented on GitHub (Jan 29, 2018):
Wednesday May 11, 2016 at 18:38 GMT
The playback time issue was caused by some stupid unit conversion mistake, and fixed by
b8b0f9c36eShuffle and repeat are not implemented at all IIRC
@sashahilton00 commented on GitHub (Jan 29, 2018):
Saturday May 27, 2017 at 16:42 GMT
I'm finding that shuffle won't work when playing from Spotify on a Macbook Air using librespot with the Moode audio player OS on a Raspberry Pi. Have there been any updates on this? Thanks!
@sashahilton00 commented on GitHub (Jan 29, 2018):
Sunday Sep 17, 2017 at 15:47 GMT
When I enable shuffle mode due to Spotify Clients on Mac and iPhone there is no effect to Librespot. Starting the next track leads to an automated disabling of this mode in all cases.
@sashahilton00 commented on GitHub (Jan 29, 2018):
Monday Sep 18, 2017 at 02:52 GMT
@Bebowi Because it has not been implemented yet. :(
@sashahilton00 commented on GitHub (Jan 29, 2018):
Wednesday Oct 25, 2017 at 15:59 GMT
When will this be implemented?
@sashahilton00 commented on GitHub (Jan 29, 2018):
Wednesday Dec 06, 2017 at 18:24 GMT
Is there any way to get shuffle working? I want this feature so bad. Im using SpotOn (spotify alarm clock) and without shuffle its not that nice.
@sashahilton00 commented on GitHub (Jan 29, 2018):
Wednesday Dec 06, 2017 at 18:32 GMT
It works for me when I start playing on a local device (Android or desktop) and then switch output to the librespot device while playing.
@sashahilton00 commented on GitHub (Jan 29, 2018):
Wednesday Dec 06, 2017 at 19:04 GMT
That 'works' because the official client just hands librespot the already shuffled track list. Librespot doesn't really have to do anything in that case.
You can see my naive (and very incorrect) implementation of shuffle and repeat at https://github.com/plietar/librespot/compare/master...kingosticks:master. I got stuck trying to implement shuffle properly and I've some questions for anyone familiar with how it (spirc?) is supposed to work regarding this.
The incorrect aspect of what I did is that mime treats 'queued' tracks like any other track in the list. This is wrong as 'queued' tracks should keep their positions and it's only the remaining tracks that need to be shuffled. That's a simple enough improvement to do.
My problem is how do you restore the original track order when the user disables shuffle? You don't know what that original order was. Are you meant to use the context uri state to reload the track list (assuming you also fix librespot to keep that state). And then what do you do with any 'queued' tracks that are still present, just insert them at the front? I could probably answer the latter question with some more experiments but the context uri thing is a total guess.