Open mfeif opened 8 years ago
The playback time issue was caused by some stupid unit conversion mistake, and fixed by b8b0f9c36e6612f6fcb71a61ae4411556869c8f1
Shuffle and repeat are not implemented at all IIRC
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!
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.
@Bebowi Because it has not been implemented yet. :(
When will this be implemented?
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.
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.
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.
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