400 Bad Request error when using oauth, but browser authentication works

[AntitrustEnthusiast]

Describe the bug
the ytmusic.search() command is throwing a HTTP 400: Bad Request error with the message Request contains an invalid argument, but only when using oauth. Browser authentication works fine.

Using ytmusicapi version 1.8.2

To Reproduce
Steps to reproduce the behavior:

1. run ytmusicapi oauth as documented in setup
2. Minimal script example:

from ytmusicapi import YTMusic

conn = YTMusic("oauth.json")
search_result = conn.search(f"It's beginning to look a lot like Christmas")

Result:

Traceback (most recent call last):
  File "C:\dev\ytmusic\test.py", line 4, in <module>
    search_result = conn.search(f"It's beginning to look a lot like Christmas")
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\dev\ytmusic\venv\Lib\site-packages\ytmusicapi\mixins\search.py", line 183, in search
    response = self._send_request(endpoint, body)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\dev\ytmusic\venv\Lib\site-packages\ytmusicapi\ytmusic.py", line 241, in _send_request
    raise YTMusicServerError(message + error)
ytmusicapi.exceptions.YTMusicServerError: Server returned HTTP 400: Bad Request.
Request contains an invalid argument.

Additional context
I've been using it for quite a while without issue, but today it stopped working, seemingly at random. Switching to browser auth has temporarily fixed it for my workflow.

Deleting oauth.json and redoing the authentication flow didn't work either.

[zostay]

I too have started getting this, though, I can't get the browser auth to work either.

[sigma67]

Could you try messing with the headers to see if removing some fixes it? Hard to tell what the issue is without further indication

[AntitrustEnthusiast]

Hmm, I ran test requests using this code:

from ytmusicapi import YTMusic
conn = YTMusic("oauth.json")
conn.rate_song("A4zBSnMhvI0", "LIKE")

While removing one of these headers each time:

• user-agent
• accept
• accept-encoding
• content-type
• content-encoding
• origin
• authorization
• X-Goog-Request-Time

All of them except authorization returned the exact same error message: Request contains an invalid argument.

Here's the full error from the API, in case it helps:

{
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "errors": [
      {
        "message": "Request contains an invalid argument.",
        "domain": "global",
        "reason": "badRequest"
      }
    ],
    "status": "INVALID_ARGUMENT"
  }
}

Also tried removing ?alt=json from the endpoint, no change.

The only one that had a different result was removing the authentication header, which returned a You must be signed in to perform this operation. error.

[rafaeldrrmachado]

Does anyone know where the oauth.json file is stored? I can't findi it to try and delete it

[srajangarg]

same issue, commenting for visibility!

guessing its a server side change that break the api

[AntitrustEnthusiast]

Someone in the linked spotify_to_ytmusic issue mentioned it works for them as Manager of their family plan, but not for their wife and kids (non-managers).

I am in the same situation (non-manager), is everyone else experiencing the issue also a non-manager on a family plan?

[hhh4hn]

everyone else experiencing the issue also a non-manager on a family plan?

This seems related to what I've noticed: it's working fine for me when using oauth creds for one account that is a primary account of mine, but it does not work on another which is a "brand account" under a second account. I get 400: Bad Request on any call using that brand account.

Edit: on further testing, it seems like my 2nd account (which is under a family plan), whether I use its primary or brand account, fail with this error, so my experience supports @AntitrustEnthusiast hypothesis.

[apastel]

everyone else experiencing the issue also a non-manager on a family plan?

My account is the manager of my family plan and I get the 400: Bad Request error when using oauth creds.

[sabad67]

i am seeing this issue as a manager of a family plan.

[soreikomori]

Same here when calling yt.get_history(). I also tried updating to no avail. Currently on ver. 1.8.2.

[sigma67]

I doubt this is related to family plans, likely just a coincidence.

I would suspect that something in here broke/needs to be updated due the server-side update: https://github.com/sigma67/ytmusicapi/blob/main/ytmusicapi/helpers.py

I will try comparing our requests with the current requests on the web when I find time. Unfortunately I work a full time job so it might be a few days. I certainly recognize the importance of the issue given the number of reports.

In the meantime, anyone else with the time can perform the same analysis!

[secnonsense]

I have an individual plan and am also seeing this error. Maybe the issue is due to having multiple accounts on the plan? In my instance I use a branded account instead of my primary gmail.com account. I saw the error using my branded account, however after regenerating my oauth.json using my gmail.com account everything worked as expected.

[Batwam]

I'm also getting this HTTP 400 error for the last few days. Glad to see I'm not alone. I tried to generate oauth.json from 2 separate accounts and both of them fail.

[apastel]

We're all well aware that the issue is happening, now it's time for the open-source community to do its thing and come together and fix it. If you scroll up and read @sigma67's message, you'll see they are busy and some suggestions about where to look in the meantime. It's probably some header or something that changed on one of the requests in the oauth flow. I tried looking at the API docs for OAuth 2.0 for TV and Limited-Input Device Applications but nothing stuck out as being different. Also tried going through the oauth flow in the browser and looking at the requests/responses to see if there's anything that looks like one of the requests in the helpers.py file, but I might just be looking in the wrong place. The properties in oauth.json itself seem to match exactly what's expected according to that API document...

[abetwothree]

Seeing same issue. Tried multiple accounts and it all fails locally and on a server. However, it does work locally without an oauth.json file.

[apastel]

People in different projects are saying that Google is removing OAuth support for YTMusic, and they are switching back to using cookies 😢 The reason it happens for some accounts and not others of course is because of A/B testing (edit: well, global rollout, technically)

KoljaWindeler/ytube_music_player#367 (comment)
music-assistant/hass-music-assistant#3138 (comment)
yt-dlp/yt-dlp#11462 (comment)

I haven't seen anything conclusive stating this to be true, but it seems like developers of different projects are seeing the writing on the wall, which points toward bye-bye for OAuth. Let's hope that's not the case...I'm not sure how to determine if it is or not.

[jurgenweber]

The reason it happens for some accounts and not others of course is because of A/B testing.

I agree, either A/B Testing or the nature of the global rollout.

removing OAuth just seems like a direct stab at disabling these sorts of integrations.

[sigma67]

As expected this is a widespread issue affecting all third-party oauth clients: yt-dlp/yt-dlp#11462

Is anyone facing issues with browser-based auth also? Seems to be working ok for me

[srajangarg]

As expected this is a widespread issue affecting all third-party oauth clients: yt-dlp/yt-dlp#11462

Is anyone facing issues with browser-based auth also? Seems to be working ok for me

@sigma67 confirming that browser-based auth also works for me

[luisignaciocc]

For me, browser-based authentication doesn't work either. Using the get_history() (browseId: "FEmusic_history") on luisignaciocc/ytmusic-scrobbler-web#11

[Batwam]

same here, works with browser authentications, the instructions are here: https://ytmusicapi.readthedocs.io/en/stable/setup/browser.html

Is this authentication method going to have to be renewed regularly?

[sigma67]

Common advice to make long-lasting cookies is to create them using the browser's in-private session. This avoids accidentally messing with the session during your regular browsing activity

The cookies last quite long in my experience

[Batwam]

that's good to know, thanks

[Hengen42]

I couldn't manage to get cookies in the brave browser. I keep getting a 401 error.

[Hengen42]

"te": "trailers\u001a"

I solved the issue by removing this code from the browser.json file. However, I've been struggling with it for hours. It was so silly.
Example: (In the empty space, there is ["te": "trailers\u001a".] but it needs to be removed.)

{
    "accept": "",
    "accept-encoding": "",
    "accept-language": "",
    "authorization": "",
    "connection": "",
    "content-encoding": "",
    "content-type": "",
    "cookie": "",
    "origin": "",
    "priority": "",
    "referer": "",

    "user-agent": "",
    "x-goog-authuser": "",
    "x-goog-visitor-id": "",
    "x-kl-ajax-request": "",
    "x-origin": "",
    "x-youtube-bootstrap-logged-in": "",
    "x-youtube-client-name": "",
    "x-youtube-client-version": ""
}

[zostay]

I had trouble pasting directly into the ytmusicapi. My terminal choked on the long Cookie header line. The fix is easy though. Paste to a file and then:

ytmusicapi browser < headers.txt

I suspect ytmusicapi browser needs to disable some tty limit, but this works fine. I record it here in case anyone else had this problem.

[apastel]

Are you running on macOS by chance?

source: https://ytmusicapi.readthedocs.io/en/stable/setup/browser.html

[jooker]

I have my browser.json file by following the instructions at https://ytmusicapi.readthedocs.io/en/stable/setup/browser.html now how do I use it to authenticate to use the s2yt_gui and get rid of the bad request?

I dont mind using the terminal if I cant use the gui but I cant seem to find anything on using the browser.json.

[fischcode]

It looks like the maintainers of the YouTube Kodi plugin https://github.com/anxdpanic/plugin.video.youtube found a solution - at least it is playing all of a few videos I tested. I haven't quite figured out how, but it appears to be related to using the right tokens in the right place.