-
Notifications
You must be signed in to change notification settings - Fork 19
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
YouTube Music auth fails after 30 minutes #158
Comments
I haven't experienced this but its probably because I don't use YTM for extended listening, I'll see if I can get it to trigger today. 😅
your guess is as good as mine. In the underlying library, youtube-music-ts-api, cookies are returned in the response but there is no access to them from the library's exposed API. I'll see If i can introduce some code to update the cookie using responses and perhaps trigger an event emitter so multi-scrobbler can update its own config when the cookie changes. |
* Patch youtube-music-ts-api to use updated cookies from response and provide a callback on update * Implement currentCreds/build init data and read from MS-updated creds if available * Write to currentCreds when ytm-ts-api invokes auth update callback and optionally log what parts changed based on config options
I've patched ytm-ts-api and added functionality to MS to sync/write cookie changes from YTM responses to file. This should (hopefully) keep YTM source operating indefinitely and also ensure on MS restart that it uses the most up-to-date cookies. When MS updates the stored credentials it will log Please use the latest |
@roos-robert have you had a chance to test this? |
This appears to keep happening.
|
@SomeAspy how do you use YTM on mobile? Are you using the official YTM app or through a browser or something else? Also, can you confirm you turned on |
I enabled the option after that log I believe. |
* Patch youtube-music-ts-api to use updated cookies from response and provide a callback on update * Implement currentCreds/build init data and read from MS-updated creds if available * Write to currentCreds when ytm-ts-api invokes auth update callback and optionally log what parts changed based on config options
…to output changes #158 Increasing to INFO makes the signal better for long-running MS processes instead of requiring logging all of DEBUG
Do you have Regardless I've added a change that will force auth changes to log to INFO now (when |
Auth dropped again :(
|
Thanks for verifying the auth updates are taking place. I'm honestly not sure how else to diagnose this. I am using Firefox to get the cookie/authUser values and have not had any issues with 401ing. If you are not using FF could you try that? YTM must be doing something to detect MS usage is not a valid user and expiring that session/cookies but what is causing, I don't know. The library MS uses, youtube-music-ts-api, was inspired by python library ytmusicapi which has since moved on to using oauth. I'm sure its doable to replicate this for yt-music-ts-api but it's a little out of the scope of MS and what I want to handle workload-wise at the moment. I'm open to other suggestions on how to diagnose this or collaboration on getting youtube-music-ts-api up to date. |
I am indeed using Firefox to pull cookies. Frustrating to see YouTube music being so hostile towards any sort if integrations. |
Was a long shot, but no such luck. |
Sorry for the late reply, weeks around Midsummer are always crazy busy. I've not yet had the time to test this out but by the looks of it (thanks @SomeAspy) it seems that the issue persists, perhaps that's one of the reasons behind https://ytmusicapi.readthedocs.io/ moving on to oauth. Just before hitting busy times I actually collaborated on a Python script using the library mentioned above, being able to auth with oauth solved all the issues regarding auth and been running that little worker for around 2 weeks now without any issues. So the idea of updating the TS library as well seems to me like the best route (but I 100% get it's far out of scope for you/this project). If I have the time I might be able to take a look at it later. Python script is just like a soggy band-aid compared to being able to use this, love the solution, hating that Google is making it so hard for no reason. |
Finally some testing and an update from me as well, unfortunately facing the same issues as indicated by the log:
Scrobbler runs great for like 2 hours then this happens, tried copying and using the cookie from Firefox and Chromium based browser with same result. So the conclusion regarding OAUTH seem to stand, wouldn't call this a bug rather a "feature" introduced by Google and thus breaking the old TS-based API. |
Sorry for interupting, but how can i force multiscrobbler to scrobble music from ytmusic android app? Spotify on android and ytmusic on my computer are working great. |
As far as I know it should work the same as using it on your desktop. YTMusic records your listening history to a playlist that MS monitors for changes. If the YTMusic android app doesn't cause that playlist to be updated there's nothing MS can do about it, unfortunately. |
…to output changes #158 Increasing to INFO makes the signal better for long-running MS processes instead of requiring logging all of DEBUG
The cookie updates and logging for these updates is in v0.8.3. There are also mentions of this issue in the FAQ and ytm source configuration docs. Since YTM is a blackbox I can't do anything about YTM deciding to invalidate credentials other than explain the situation and point users back to refreshing their credentials manually. If someone discovers a workaround for this I'm happy to revisit in the future. |
@SomeAspy @roos-robert can you please try out the new YTM auth found in #203 and let me know if this fixes intermittent auth issues for you -- |
Describe the bug
This is more of an FYI report since it's hardly a bug- more of an issue with YouTube Music authentication. I've noticed that the cookie seems to change with 30-60 minute intervals, whereas the scrobbler is no longer able to authenticate and fetch the play history.
Excerpt of the part of the cookie changing:
Doing a copy+paste of the new cookie to config.json makes the authentication work again for ~30 minutes.
The behaviour is the same regardless if using the browser to stream, 3:rd party desktop app or mobile app.
To Reproduce
Expected behavior
To have the session stay alive longer, I'm guessing that since I'm not logged out of any of the apps/browser that perhaps it's some kind of token refresh causing the auth error in multi-scrobbler
Logs
Versions (please complete the following information):
The text was updated successfully, but these errors were encountered: