mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #288] Starting playback fails if uri or context_uri is provided #193
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#193
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 @forslund on GitHub (Feb 19, 2019).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/288
Starting the playback of an album over spotify connect
Endpoint:
me/player/play?device_id=d9464366ec73e0eda87dc781314f8f25d1df7469Data:
{'context_uri': 'spotify:album:6eGYLONkDMja0MNtZWnRRB'}Results in the librespot player debug output:
This is the last track I played on my desktop spotify player
If I try to just start playback
Endpoint
me/player/play?device_id=d9464366ec73e0eda87dc781314f8f25d1df7469Data:
{}Results in no further output but playback of the above loaded track starts.
Update:
Request for single track using normal uris:
Endpoint:
me/player/play?device_id=d9464366ec73e0eda87dc781314f8f25d1df7469Data:
{'uris': ['spotify:track:5fpizYGbi5IQoEraj6FP0R']}This is on HEAD of master
d2cadec419@kingosticks commented on GitHub (Feb 19, 2019):
Last time I looked, librespot didn't support loading things from a context uri (https://github.com/librespot-org/librespot/issues/57). Have you tried passing the individual tracks via the
urisparameter instead?@kutmasterk commented on GitHub (Feb 19, 2019):
I have the same issue since today.
Something changed on spotify's end.
I cannot select any track for playback. Librespot always resumes the last played track.
@forslund commented on GitHub (Feb 19, 2019):
Huh, weird I've been using context_uri's for quite some time. (more than a year)
In any case the uris doesn't work either:
Endpoint:
me/player/play?device_id=d9464366ec73e0eda87dc781314f8f25d1df7469Data:
{'uris': ['spotify:track:5fpizYGbi5IQoEraj6FP0R']}@forslund commented on GitHub (Feb 19, 2019):
Thanks for confirming @pizzaboy75
@kingosticks commented on GitHub (Feb 19, 2019):
Maybe a debug log will shed some light on what's go on. You can specify a specific module by setting the
RUST_LOGenvironment variable appropriately.@forslund commented on GitHub (Feb 19, 2019):
Thanks, sadly atleast to me it yields very little, this is for 'spotify:track:5fpizYGbi5IQoEraj6FP0R':
Seems there is not very much debug! statements when processing the frames recieved. I'll keep digging but other people are more likely to find the reason for this.
To me it seems like the piece of code extracting the new tracks fail to insert anything new and whatever was there previously gets loaded instead.
@forslund commented on GitHub (Feb 19, 2019):
Added some extra debug prints and it seems like
MessageType::kMessageTypeLoadthat's processed is always the last thing that actually played. But the status is set tokPlayStatusPauseso the playback isn't resumed.@mordax7 commented on GitHub (Feb 20, 2019):
Same Issue here, I cannot change playlists after selecting one song from the playlist....
@kutmasterk commented on GitHub (Feb 20, 2019):
I think this can be resolved if someone translates the changes made here:
github.com/librespot-org/librespot-java@c1006ec29eto librespot.
@forslund commented on GitHub (Feb 20, 2019):
Hmm, maybe...
I just tried reverting that update. And that still loads the correct uri, it just pauses the playback right after.
Might be something related to that still...
Edit: I tried adding the same check but with the same result as previous. :(
@forslund commented on GitHub (Feb 20, 2019):
Added some more debug prints to get a handle what's happening and it seems the No frame loading the new uri reaches handle_frame
For starting playback of context_uri': 'spotify🧑🎨67ea9eGLXYMsO2eYQRui3w'
@maciekczwa commented on GitHub (Feb 20, 2019):
I have the same - cannot change songs
@aksel commented on GitHub (Feb 20, 2019):
Same here. It loads the track that is currently playing, no matter what track I select.
I also get the following error, though I am unsure if it is reported by librespot or the client I'm using (spotifyd):
Vorbis error: InitialFileHeadersCorrupt@warro commented on GitHub (Feb 20, 2019):
Same problem here.
@forslund commented on GitHub (Feb 21, 2019):
Here's a short comparison with the java version loading sequence
librespot-java:
librespot:
The second frame seems to be new but contains the same context_uri as the first frame.
Any ideas on what more I can do to help debugging this?
@wdehoog commented on GitHub (Feb 21, 2019):
Is the java player really working?
Does Librespot send stuff to spotify as well? And can you log it? If every frame sent to spotify contains the same tracks in its State data maybe Librespot sends something that make Spotify prevent sending new context or tracks.
@worleydl commented on GitHub (Feb 21, 2019):
Yes, librespot-java is functioning as expected. I dug a little last nite and tried incorporating the play-token fix from that project into librespot but no luck so far. I'm not positive it's related but I saw it mentioned here.
@forslund commented on GitHub (Feb 21, 2019):
I tried librespot-java without the pause fix and that still loads the correct playlist/tracks so I'm pretty sure there's something else afoot as well.
I'm going to try adding more debug of what is actually sent back to spotify before the new tracks are received in the two versions, but I'm basically just stumbling blindly here
@worleydl commented on GitHub (Feb 21, 2019):
When looking at the frames recieved in spirc: The java client is getting a protocol version of 2.0.0, rust is showing 3.0.1
@worleydl commented on GitHub (Feb 21, 2019):
Removing the 3 from https://github.com/librespot-org/librespot/blob/master/connect/src/spirc.rs#L217 fixes the issue but I don't know if it causes other issues in the app.
@forslund commented on GitHub (Feb 22, 2019):
@worleydl you should make a PR with that change. So far your change is working for me, I'll continue to test during the day.
@devgianlu commented on GitHub (Feb 22, 2019):
@worleydl Did you trying using 4 instead of 3? Does the protocol version change?
@kutmasterk commented on GitHub (Feb 22, 2019):
I did a little digging and i found that @plietar changed the Connect mercury URL to
/3/with this commit in May 2017:github.com/plietar/librespot@7c237c77dfI think this was done in a whole set of fixes for this particular Issue:
https://github.com/plietar/librespot/issues/185
@forslund commented on GitHub (Feb 22, 2019):
@devgianlu, I tested with 4 instead of 3 and that results in a panic on startup, due to a 404 response.
@ofosos commented on GitHub (Feb 22, 2019):
Removing
/3works for me.@sashahilton00 commented on GitHub (Feb 22, 2019):
I personally can't reproduce this, my guess is it's somewhat dependent on client version, or they're rolling out updates. Given that it's a 1 line URL change, and it seems to solve the issue, I would assume that the fix should be fine to implement, given that it's just a resource locator, and doesn't affect any of the actual librespot logic. If someone wants to create a PR with the change, please also include a short comment in the line above to issue #288 so that if problems sub sequently crop up, it's easy to arrive at this issue and we can continue working a fix from there, we'll merge it.
@kingosticks commented on GitHub (Feb 22, 2019):
@sashahilton00 did you try the fix out on your account that doesn't have the issue? i.e. does it continue to work or does it break it?
@sashahilton00 commented on GitHub (Feb 22, 2019):
It was working fine when I tested the one liner.
On 22 February 2019 at 14:18:54, Nick Steel (notifications@github.com)
wrote:
@kingosticks commented on GitHub (Feb 22, 2019):
Ok, great, just checking. (I just found that I don't have this issue either. Good ol' reliable Blighty!)
EDIT: I tell a lie, I do have this issue. I just messed up reproducing it.
@kingosticks commented on GitHub (Feb 22, 2019):
This does seem to have resolved the issue, however I will just note here that my official desktop client is still happily talking to the original
hm://remote/3/user/<username>endpoint. We might need to come back to this.@sashahilton00 commented on GitHub (Feb 22, 2019):
@kingosticks hmmm, we (myself and @ashthespy) were seeing similar behaviour with the dailymixes endpoint, whereby the desktop clients were getting from the endpoint just fine, but any attempt to do so from librespot failed. I think there's some initialisation/authentication that they've started to add to endpoints that we'll need to work on at some point if it becomes more pressing.
@devgianlu commented on GitHub (Feb 22, 2019):
I've noticed that, I don't know if it's related. Also that
@kristaps194 commented on GitHub (Feb 22, 2019):
Hi! Sorry for the silly question, I'm new to git...
How do I update my Raspotify Librespot with the ommitment of this 3?
I don't see I could remove it from any text file, so I guess I should somehow delete the current install from RPi, compile and install this new one somehow?
I don't expect you walking me completely throught this but at least a link or comment on the right direction would be appreciated :)
@worleydl commented on GitHub (Feb 23, 2019):
This project contains a docker setup to do cross platform builds. Build for your platform and replace the files in raspotify.
Reference https://github.com/librespot-org/librespot/wiki/Cross-compiling
@peterdk commented on GitHub (Feb 23, 2019):
Nice, this fixed it for me as well. I couldn't select a new song or playlist, only thing that worked was enabling local playback, select song, then enable raspotify again as output.
@peterdk commented on GitHub (Feb 23, 2019):
@kristaps194 To compile an updated version of raspotify, refer to the
Building the Package Yourselfsection on https://github.com/dtcooper/raspotify/blob/master/README.md . I just updated my raspotify and it works again.@kristaps194 commented on GitHub (Feb 24, 2019):
@peterdk thank you for your response! Yesterday I cloned the package and tried to "make" it. First time it compiled for ~15 minutes on my RPi 2. It compiled with errors, couldn't connect to alsa web page. In raspotify folder didn't find any deb package.
Today I updated "make" and tried to rebuild the package (w/o deleted previously cloned content). It finished in less than 1 minute with the same error but significantly less logs (~200 lines vs ~20). Tried to install ufw to simply open port 21. Got kicked out from SSH session and manually restarted. After that quite miraculously switching playlists now works. Perhaps Spotify did something on their end because after building the package I didn't try updating either raspotify or librespot.
Anyway - just wanted for you guys to know how it ended :)
@morloy commented on GitHub (Mar 7, 2019):
librespot.zip
Here’s a build of the current
librespotfor the Raspberry Pi. Tested and working on moOde.@devgianlu commented on GitHub (Mar 10, 2019):
I've did some packet dumping and noticed that the communication style is different for
hm://remote/3/user/.../. You don't need toSUBto the uri anymore, instead they usePOSTfor sending and the events are sent with packet type0xb5.Here it is the fix forThis did not fix anything.librespot-java.@kingosticks commented on GitHub (Mar 10, 2019):
Good work!
@devgianlu commented on GitHub (Mar 10, 2019):
Just did some extensive testing and it doesn't work.
Hopefully I can sort it out easily.I'll be investigating this behavior when I have time.@ashthespy commented on GitHub (Mar 11, 2019):
@devgianlu Dunno if it is of interest - but I recall noticing quite some chatter via the
hm://event-service/v1/eventsendpoint@devgianlu commented on GitHub (Mar 11, 2019):
These seem to be just for collecting analytics data. What I've noticed is that the client receives a load event, but with the old context. The correct context is sent along with a play event.
I desperately need to improve the dissect tool, if someone can help, please contact me on Gitter.
@devgianlu commented on GitHub (Mar 12, 2019):
I've started the huge process of reversing the new protocol. Testers are (very) welcome and contributions are appreciated. See https://github.com/librespot-org/librespot-java/pull/54.
@mfeif commented on GitHub (Mar 16, 2019):
@morloy is that all the audio backends? (I need pulseaudio...)
Thanks for sharing!