New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix spotify controller and update example #509
Fix spotify controller and update example #509
Conversation
@fondberg could you take a look at this please? |
@shocklateboy92 , @CraigDropTables how has this been tested? The pychromecast spotify functionality is used in some other places, for example spotcast, and since we change the required arguments for starting the app, those need to be updated too? |
break | ||
# The chromecast device does not show up as part of the public API get devices | ||
# call until it starts playing. The only way to do so is to transfer playback | ||
# by call this endpoint that's not part of their public API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm. I think this is not correct.
It will should show up. I dont need any special http calls
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Odd. How long did it take to show up? Was it a Chromecast V1/V2? or Google Home/Mini?
Did you use the auth token fetched by feeding your cookies to spotify_token
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I maintain spotcast so I think I represent most of the users with a variety of cast devies
@@ -11,10 +11,9 @@ | |||
APP_NAMESPACE = "urn:x-cast:com.spotify.chromecast.secure.v1" | |||
TYPE_GET_INFO = "getInfo" | |||
TYPE_GET_INFO_RESPONSE = "getInfoResponse" | |||
TYPE_SET_CREDENTIALS = "setCredentials" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on the net-export log, our web player wasn't sending this anymore. We tried it with the same auth token, and it still returned setCredentialsError
. Doing the same addUser
the web player was sending worked.
TYPE_SET_CREDENTIALS_ERROR = "setCredentialsError" | ||
TYPE_SET_CREDENTIALS_RESPONSE = "setCredentialsResponse" | ||
|
||
TYPE_ADD_USER = "addUser" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you describe what this new api call does?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as we can tell it does the same thing that setCredentials
used to do, with the payload in a slightly different format.
Sorry for the late response. We tested this on our Google Home (and Google Home Mini). We originally tried it with Home Assistant, and noticed it made the "ding" noise but then got stuck. Looking at the logs, it looked like our Google Home as returning So we followed the instructions on this project's readme.md and used net-export to look at what the spotify web player sends. |
interesting. so will this fix the expiry issue after 60 mins (token expiry)? also I think we need to test this on many more devices before releasing as it seems it works as is for a lot users |
"Authorization": "Bearer " + access_token, | ||
} | ||
transferResponse = requests.post( | ||
"https://guc-spclient.spotify.com/connect-state/v1/connect/transfer/from/noop/to/{}".format( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
guc is for US.
It is not advisable to use spotify internal API:s. A simple force_playback with spotipy should suffice like here https://github.com/fondberg/spotcast/blob/e17716a30e54a7a7c08110ea315a9debb6bf0fac/custom_components/spotcast/__init__.py#L154
Clearly I did not test the existing functionality enough. I tested Spotcast last night and it works for us so we may just need to update the example for now. As Spotify is now using addUser instead of set credentials the setCredentials flow may break in the near future but I don't see a need to switch from setCredentials to addUser until the workflow breaks. |
Seperate from this but... what would be interesting is to see what happens after 60 mins when sniffing. Is there a new token sent? |
What's the way forward for this PR? |
@emontnemery seems they were right. The old setCredentials is not working anymore. |
Unfortunately @rako77 and I are a little squeezed for time at the moment.
We'll see what we can do when things calm down in a few weeks.
…On Sun, Aug 15, 2021 at 7:38 AM Niklas Fondberg ***@***.***> wrote:
@emontnemery <https://github.com/emontnemery> seems they were right. The
old setCredentials is not working anymore.
@rako77 <https://github.com/rako77> can you merge master and take this
forward?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#509 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGRDLKQ6SEEKRLWC4TP54DT47GQBANCNFSM46UBV5FQ>
.
|
The Spotify controller is moved to spotcast so this can be closed |
Thanks! |
It seems the
setCredentials
message has changed toaddUser
at some point in the past, with a different payload.We also discovered a new issue with playback (on our google homes and chromecasts at least) where launching the spotify app and adding the user/token to it doesn't cause it to appear in spotify's device list. This updates the example to make the same request the web player does to enable playback on the cast device.