New YTMusic Cookie Format? #195
Comments
|
You should update your instance of Multi-Scrobbler...the last year of updates has really improved MS's stability and added a ton of features including knowing what version you are on. However I am able to reproduce on current MS versions as well. The endpoint is for MS uses another library to facilitate this communication so it's not something I can immediately fix or investigate but it looks like other projects relying on the endpoint are having issues as well. It may be that Youtube Music hanged their undocumented API endpoints or there is an internal issue that could be resolved. |
|
Coming from #199. Here are my logs, exactly the same as @FoxxMD: |
|
Mostly talking to myself here but I've confirmed that the liked music endpoint still works when using oauth authentication with the original ytmusicapi python library. Using browser authentication, which is what yt-music-ts-api (MS) uses, is what is failing when trying to hit the endpoint. |
|
@jrlebbs @bockbilbo please try out the new YTM auth in #203 and let me know if this fixes things for you -- |
|
@FoxxMD the new pr is not working, I am getting an exception for a missing package: |
|
Please pull the latest PR image and see if that works, thanks |
|
I have tried pr-203 and pr-205. The logs from my previous message are for pr-203. pr-205 was not even booting. What latest PR image do you refer to? |
|
Please try re-pulling |
|
Thanks @FoxxMD . I have tried again, and have confirmed the version. The tool is prompting me a code to Re-authenticate into Youtube Music, but redirects to an internal website "/api/source/auth?name=Youtube%20Music&type=ytmusic" that returns "Internal Server Error". Here are the logs from the app in Docker: My guess is that i should have been redirected to a youtube page to enter the code to authenticate myself. Do i need to enter some kind of Youtube developer API token in the multi-scrobbler configs? |
|
Actually.. I was able to connect to youtube music and scrobble music played from their website! Scrobbling is not working though when I play music from the Youtube Music app. Is that behavior expected? I found this log on the tool: I used the google.com/device url to make it work! I guess that the redirect url link in the app needs review? |
|
Ok, I've got 0.8.5 installed. When I run npm start (before I get 203 merged), this happens: MINGW64 ~/multi-scrobbler-0.8.5
'NODE_ENV' is not recognized as an internal or external command, |
Yea so I was able to do the same, and it does work with mobile app for me. But I noticed that it "discovered" 20 tracks, which were the last ones I had played before setting up the scrobbler. If I try to play those, it doesn't scrobble, but anything not on that list scrobbles. However, they get added to that list and don't scrobble anymore if I replay the song. Is this intended an behavior?
|
|
@MyNameHand I have experienced the same behavior. After my first run, multi-scrobbler got the 20 Youtube Music plays before setting up the scrobbler, but then did not update despite refreshing every 10 seconds. A day later, it refreshed some 10 songs I played from my google speaker, but then stopped detecting more after that. @FoxxMD I wonder if there is a problem with the code part that retrieves and refreshes the cache from Youtube Music. Or could it be a problem with the google url used to get the data? |
|
Yeah I need to do some more due diligence on how the data returned looks compared to the previous cookie method. The current changes in #203 were just to see if oauth would work (At all). Will look into the behavior ya'll have described this week. |
|
Looks like YTM made other changes other than blocking cookie-based retrival of the history endpoint. The way it returned data it used to include all instances of played songs (without a timestamp) but they were at least ordered based on when they were played IE: Now, it's removing the earlier play and putting it at the front of the list: Since YTM doesn't provide timestamp and the api doesn't allow tracking the player in realtime the logic used to determine new plays is dependent on the history order being "valid" with some heuristics. The new behavior is causing it to throw away the remove-and-bump differences which only affects tracks that are played again within YTM's history window. |
Should fix new way YTM orders recent history #195
|
Please update to the latest image of |
|
It works!!! I have just played song A, then song B, then song A again from the browser, and the three were recorded! :) I will continue to test in the next few days and get back if there is any problem. Thanks a lot @FoxxMD |
|
Alright... so.. after the test above, i tried using Youtube Music on my phone, and the song I played was scrobbled. However, a song I played a few days when testing was also scrobbled with the current timestamp. |
|
@FoxxMD, I've got pr-203 pulled into docker, but when I try to run, I get the error below. Any thoughts on what I can do to fix? docker run -v "$(pwd)/config:/config" -p 9078:9078 foxxmd/multi-scrobbler:pr-203 |
|
I cannot reproduce that error and nothing has changed about the docker image with this PR. Are you using portainer for container management? If so make sure command and Entrypoint are set to default
|
|
No, I'm not using portainer. Just pulled the image and ran it with the commands. |
|
I'm also fine just to wait until 203 is merged with main and pull the new main version, since it seems like other people's testing is working. |
|
@bockbilbo I've added a new config option that will help with troubleshooting what tracks are scrobbled. Please pull the latest [
{
"name": "MyYTMusic",
"enable": true,
"clients": [],
"data": {
},
"options": {
"logDiff": true
}
}
]This will make MS log to DEBUG the list of tracked history and how it was modified each time MS decides to scrobble new tracks. Please see if you can reproduce the unexpected behavior and then describe in as much detail what you did along with logs from before/during/after the behavior occurred. You may also need to enable MS to log to debug for docker output/file by setting the env The logged history diff should look something like |
Please check the FAQ before submitting a bug report.
Describe the bug
YouTube Music stopped authenticating as a source about 3 days ago. Logged in following the guide and the cookie now starts with "HSID" instead of "SID"
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The cookie should auth YTMusic.
Logs
If possible reproduce the issue with debug logging ON
Versions (please complete the following information):
Provide version information for any related sources/clients.
-- running on windows
Additional context
I have tried several ways, reboots, etc. to get this to work. I suspect the cookie format has changed and I'm happy to provide more cookie details, just unsure of what's secure or not to be careful with.
Happy to help in any way!
The text was updated successfully, but these errors were encountered: