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 |
|
@bockbilbo I can't reproduce your behavior (have tried several times now) so until you try the new changes and give me some new logs I can't diagnose this further. Also, unfortunately, I can't test YTM on mobile because I do not have premium and it seems that YTM mobile plays of videos do not count towards "recent history" (songs only play on mobile with premium) |
Should fix new way YTM orders recent history #195
|
@FoxxMD I just pulled the latest version of pr-203 into docker and ran. It's working with YTM from both web and mobile! |
|
I have the same problem and im checking out the new oauth method (#203) right now, I think the latest docker image has this PR but looks like the website hasn't been updated with the new oauth docs |
|
@UditDey correct the website does not have the updated instructions. Those will be added once the PR is included in a release. Please use the instructions included in the PR's original comment OR the updated docs should be available locally from your MS instance (using the PR image) if you open the dashboard and click on Docs
|
|
@FoxxMD I also can confirm that using voice commands on my google home device to start playback scrobbles correctly as well! |
feat(youtube)!: Use oauth-based api library for better stability
|
This is available on the |
|
@FoxxMD I am sorry for the late reply, I have been out for the last couple of weeks. Thanks for continuing working on the request. I have tested the latest foxxmd/multi-scrobbler:edge docker image (master-eb26ee0) and have noticed that I am being asked to re-authenticate into YoutubeMusic every time I restart the container. Is this an expected behavior? Also, I want to verify if the problems I reported a few weeks back are still happening. I will reply back with findings. For reference, below are my YTM settings in the config.json file. I don't think the cookie is needed anymore, right? |
|
I was not able to reproduce the problem I reported 2 weeks ago about songs being re-scrobbled. If I see it happening again, I will open a new issue to address it, but I am guessing that the changes made by @FoxxMD might have fixed it. Also, I just made a test of playing some music on my browser, phone and nest hub, and everything worked as expected. The debug logs are also nice to see, the history diff is useful to see how MS is working in the backend. |
This is the last pending question I have. I wonder if other's have the same problem. I have verified that the youtubei_oauth_credentials directory containing the oauth credentials has the right permissions. Is there anything else I should check? |
|
It should not be asking you to reauthenticate everytime. Can you post startup logs? |
|
Here you go, there is a 400 error triggering the reauthentication request: |
|
Do you have a
it would probably say |
|
I use a combination of ENVs and config setup. ENV Settings: Config setup: And, yes, I do have the yti-Youtube Music folder: 
|
|
Thanks for the details, I'll see if i I can reproduce this |
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: