mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 00:05:55 +03:00
[GH-ISSUE #1099] Unable to get client token after control playback using the api. #511
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#511
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 @GiviMAD on GitHub (Jan 13, 2023).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1099
Hi, I have facing a bug when trying to use the version from the dev branch, this bug is not present on the 0.4.2 version, which is working great for me at the moment :).
I have just tryed this using macOS, but I think the bug is reproducible on other platforms.
The steps to reproduce the bug are the following:
After taking a look I think that the problem was introduced by this changes
github.com/librespot-org/librespot@10650712a7.What I has discovered after adding some logs is that when I use the api to start the playback a client id that don't match any of the present in the core/src/spclient.rs is used due to this code .
My suspicious is, maybe the client id do not have permissions to use the "streaming" scope? I tried to force it to use the KEYMASTER_CLIENT_ID but this do not solve the problem, maybe other places have been changed to relying on data of the last connected device.
I think that the problem will not only affect to the playback initialization but also will make the token renewal fail whenever it is done after librespot has been controlled using the api.
Probably all of this will make more sense to the maintainers, hope some of this helps to find the problem.
@roderickvd commented on GitHub (Jan 14, 2023):
I think you are on to something with your analysis. I won't have time to look at this anytime soon, but I can look at PRs and offer advice if I have any.
Here I would appreciate it if someone else could do the trial-and-error thing (or actual packet analysis) of swapping in and out parts of that commit and other keymaster changes, to see what triggered this, so we may work on a fix from there.
@kingosticks commented on GitHub (Jan 16, 2023):
I can't reproduce this. I'm not 100% sure I am doing exactly the same, the above steps are a little vague. A debug log would be useful.
I do see lots of failures to get a client token but that doesn't stop the playback (for me). I don't know the dev code well enough to understand why playback can continue despite this.
@roderickvd commented on GitHub (Jan 16, 2023):
The client token is required for only some of the HTTP endpoints. That's why the code is lenient to try anyway if no client token could be gotten.
@kingosticks commented on GitHub (Jan 16, 2023):
Ah ok! So, a client token (and therefore an access token) isn't actually required for CDN access and for playback itself? Maybe there's hope for #1098 after all...
@roderickvd commented on GitHub (Jan 17, 2023):
That’s right.
@roderickvd commented on GitHub (Jan 17, 2023):
To be clear there are two types of tokens: the “keymaster” one (your choice with a hardcoded token or one gotten from the session) and the “spclient” token which is required for some HTTP endpoints, but indeed not the CDN.