Login to youtube fails

[olifre]

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2016.11.22. If it's not read this FAQ entry and update. Issues with outdated version will be rejected.

• I've verified and I assure that I'm running youtube-dl 2016.11.22

Before submitting an issue make sure you have:

• At least skimmed through README and most notably FAQ and BUGS sections
• Searched the bugtracker for similar issues including closed ones

What is the purpose of your issue?

• Bug report (encountered problems with youtube-dl)
• Site support request (request for adding support for a new site)
• Feature request (request for a new functionality)
• Question
• Other

---

The following sections concretize particular purposed issues, you can erase any section (the contents between triple ---) not applicable to your issue

---

If the purpose of this issue is a bug report, site support request or you are not completely sure provide the full verbose output as follows:

Add -v flag to your command line you run youtube-dl with, copy the whole output and insert it here. It should look similar to one below (replace it with your log inserted between triple ```):

$ youtube-dl --verbose :ytwatchlater --netrc                                                        1 ↵
[debug] System config: []
[debug] User config: [u'-fbestvideo+bestaudio,0,best,']
[debug] Command-line args: [u'--verbose', u':ytwatchlater', u'--netrc']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2016.11.22
[debug] Python version 2.7.10 - Linux-4.8.3-gentoo-x86_64-Intel-R-_Core-TM-_i7-4910MQ_CPU_@_2.90GHz-with-gentoo-2.3
[debug] exe versions: ffmpeg 2.8.8, ffprobe 2.8.8, rtmpdump 2.4
[debug] Proxy map: {}
[youtube:watchlater] Downloading login page
[youtube:watchlater] Logging in
WARNING: unable to log in: HTTP Error 400: Bad Request
[youtube:watchlater] WL: Downloading webpage
[download] Downloading playlist: WL
[youtube:watchlater] playlist WL: Downloading 0 videos
[download] Finished downloading playlist: WL
...
<end of log>

---

Description of your issue, suggested solution and other information

Login to youtube fails. Needless to say, password and account name in .netrc' are fine, and manual login to the page works. The same output is obtained if using -u myaccountname@gmail.comand entering password manually, so also the.netrc' file is likely not broken. I do not have 2-factor auth activated for my account.

Is use of oauth (like e.g. offlineimap supports) available?

[olifre]

That does not fix my issue, I still get, as before:

[youtube:watchlater] Logging in
WARNING: unable to log in: HTTP Error 400: Bad Request
[youtube:watchlater] WL: Downloading webpage

since my issue here is happening during login, before the download of the watchlist even takes place...

[dstftw]

Post the output with --dump-pages.

[olifre]

Here you go: http://pastebin.com/Dm3KH27e

[olifre]

After some more testing, I found that after many attempts, it sometimes works!
Switching to google DNS instead of using my provider DNS (which reveals a different IP for youtube of course), it works almost every time - although after several attempts, I finally get:

WARNING: unable to log in: bad username or password

which is probably google blocking the plaintext login (waiting for some time + retry makes things work again).

So right now I believe the error 400 may indeed be a "local" issue: A problem with the youtube-server for which my provider hands out the IP via DNS.
OTOH of course the "bad username or password" in case of too many login attempts (I believe this is when google provides a captcha to solve?) is not nice - here I guess using oauth would help (as e.g. offlineimap does, it can always login to my googlemail account without any issue).

I'll watch the problem a bit more in the next days and see whether it also vanishes if I am in different networks (with different providers and thus DNS) or I can reproduce also there.

[olifre]

I'll watch the problem a bit more in the next days and see whether it also vanishes if I am in different networks (with different providers and thus DNS) or I can reproduce also there.

Using 8.8.8.8 as DNS instead of the one my ISP, indeed everything works fine.
So I must presume it's really an issue which can only be reproduced with the IP 216.58.210.14 as youtube.de.

Maybe you can try reproducing with that specific IP? Or, if not, just close it - it seems not many people will be affected by that...

[Jessime]

Has anyone made any progress on this or run into similar issues?

I've written a small program analyze a user's Youtube history, and am using youtube-dl to grab the meta-data. Reproducibility is a problem for me as well, since logging on works fine for be, but seems to fail fairly consistently (but not always) for others.

Here's how I'm calling youtube-dl.

[namekal]

I'm having this issue currently, and setting nameserver 8.8.8.8 in /etc/resolv.conf is not fixing this. I keep getting WARNING: Unable to log in: HTTP Error 400: Bad Request. I started using -F during my tests because it kept downloading the "Free Preview" video it redirected to.

# youtube-dl -F https://www.youtube.com/watch?v=knhzSEv5Xpk --cookies newcookiefile.txt --netrc -v
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'-F', u'https://www.youtube.com/watch?v=knhzSEv5Xpk', u'--cookies', u'newcookiefile.txt', u'--netrc', u'-v']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2019.01.17
[debug] Python version 2.7.15rc1 (CPython) - Linux-4.15.0-43-generic-x86_64-with-Ubuntu-18.04-bionic
[debug] exe versions: ffmpeg 3.4.4, ffprobe 3.4.4
[debug] Proxy map: {}
[youtube] Downloading login page
[youtube] Looking up account info
[youtube] Logging in
WARNING: Unable to log in: HTTP Error 400: Bad Request
[youtube] knhzSEv5Xpk: Downloading webpage
[youtube] StWn91-HQHA: Downloading webpage
[youtube] StWn91-HQHA: Downloading video info webpage
...

Here is the pastebin for --dump-pages:
https://pastebin.com/L22mcBq4

[Mikeltxo15]

Okay, after fiddling with it for a little bit i got it to work. Setting nameserver to 8.8.8.8 in resolv.conf didn't work at first because NetworkManager was overwriting the file at boot-time. After write-protecting it, i got it to work consistently. @omeringen @Quaraxkad try this solution, or it's equivalent on Windows if you are a Win user, and with luck it will fix your problems as well.

[TheDaChicken]

I don't know this information for sure, but I think Google Login now fully requires JavaScript, kinda of.
I found that Google Login will work if challenge has a "bgRequest" identifier in the form data. Try logging-in Then, removing that identifier causes it to go through the challenge without the bgRequest identifier. Weird.

I was able to login yesterday, without doing this. But for some reason, today Google started giving me a 400 Bad Request.

[Roasty-Float]

I've been having this 'Bad Request' issue for a week or more now. It is consistent across three different internet services and does not care about a static DNS server(s) or ISP assigned. The downloader works great when directed at a batch file, playlist, or individual video, only when attempting to login to an account the problem appears.
Anyway here's the '-v' from my system.

[redacted]:~$ youtube-dl :ytsubs -v
[debug] System config: [u'-f', u'bestvideo[height<=?1080]+bestaudio/best', u'-o', u'/media/[redacted]/5371-9A72/Downloaded_Videos/Subs/%(uploader)s/%(title)s.%(ext)s', u'--sleep-interval', u'4', u'--max-sleep-interval', u'12', u'--netrc', u'--dateafter', u'now-3days', u'--playlist-end', u'1', u'-i', u'--retries', u'5', u'--download-archive', u'/home/[redacted]/Videos/Vid_archive.txt']
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u':ytsubs', u'-v']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2019.06.08
[debug] Python version 2.7.13 (CPython) - Linux-4.19.42-v7+-armv7l-with-debian-9.9
[debug] exe versions: ffmpeg 3.2.14-1, ffprobe 3.2.14-1
[debug] Proxy map: {}
[youtube:subscriptions] Downloading login page
[youtube:subscriptions] Looking up account info
[youtube:subscriptions] Logging in
WARNING: Unable to log in: HTTP Error 400: Bad Request
[youtube:subscriptions] Youtube Subscriptions: Downloading webpage
[download] Downloading playlist: Youtube Subscriptions
[youtube:subscriptions] playlist Youtube Subscriptions: Downloading 0 videos
[download] Finished downloading playlist: Youtube Subscriptions

If some of the options are confusing I can explain their combination, they function as intended without a login attempt. Also I've been trying to troubleshoot so they're likely weird. I can also provide a '--dump-pages' and '--print-traffic' at request.
Commenting here as this is an open issue that appears to be identical to the one I'm having. Other search results tend to lead me here as they are marked as duplicates of this open issue.
@dstftw

[Codingale]

I feel this could be related to having a brand name, and a personal account with one email, at least maybe? No idea, but anyways I'm having this issue too on 2019.06.08

[edmundorobles]

I feel this could be related to having a brand name, and a personal account with one email, at least maybe? No idea, but anyways I'm having this issue too on 2019.06.08

Me too.

[namekal]

I feel this could be related to having a brand name, and a personal account with one email, at least maybe? No idea, but anyways I'm having this issue too on 2019.06.08

Oh I didn't even think of that. I haven't tested it since my last comment a while back. I do have a split account. I can't quite try on another account as I was trying to use it with videos only available via Red.
(I ended up just manually pulling audio and video streams and muxing them together)

[brentil]

I as well am having this issue with both 2019.06.08 and 2019.05.20 after reverting to it.

[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--username', 'PRIVATE', '--password', 'PRIVATE', '--ignore-errors', '--mark-watched', 'https://www.youtube.com/playlist?list=WL', '-v']
[debug] Encodings: locale cp1252, fs mbcs, out cp1252, pref cp1252
[debug] youtube-dl version 2019.06.08
[debug] Python version 3.4.4 (CPython) - Windows-10-10.0.18362
[debug] exe versions: ffmpeg N-93945-g02333fe394, ffprobe N-93945-g02333fe394
[debug] Proxy map: {}
WARNING: Unable to log in: HTTP Error 400: Bad Request
ERROR: This playlist does not exist.

[omeringen]

PS C:\WINDOWS\system32> F:\vid\youtube-dl.exe -v -U -i -u *** -p *** -f "[height<=?800]" -o "F:
\vid\%(upload_date)s.%(title)s.%(ext)s" :ytsubs --match-filter "!is_live" --playlist-end 20
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', '-U', '-i', '-u', 'PRIVATE', '-p', 'PRIVATE', '-f', '[height<=?800]', '-o', 'F:\\vid\\%(upload_date)s.%(title)s.%(ext)s', ':ytsubs', '--match-filter', '!is_live', '--playlist-end', '20']
[debug] Encodings: locale cp1254, fs mbcs, out cp857, pref cp1254
[debug] youtube-dl version 2019.06.08
[debug] Python version 3.4.4 (CPython) - Windows-10-10.0.16299
[debug] exe versions: none
[debug] Proxy map: {}
youtube-dl is up-to-date (2019.06.08)
[youtube:subscriptions] Downloading login page
[youtube:subscriptions] Looking up account info
[youtube:subscriptions] Logging in
WARNING: Unable to log in: HTTP Error 400: Bad Request
[youtube:subscriptions] Youtube Subscriptions: Downloading webpage
[download] Downloading playlist: Youtube Subscriptions
[youtube:subscriptions] playlist Youtube Subscriptions: Downloading 0 videos
[download] Finished downloading playlist: Youtube Subscriptions
PS C:\WINDOWS\system32>

[Roasty-Float]

I feel this could be related to having a brand name, and a personal account with one email, at least maybe? No idea, but anyways I'm having this issue too on 2019.06.08

Oh I didn't even think of that. I haven't tested it since my last comment a while back. I do have a split account. I can't quite try on another account as I was trying to use it with videos only available via Red.
(I ended up just manually pulling audio and video streams and muxing them together)

I neglected to mention I tried on two separate accounts, one of which is devoted to the downloader and the other is a spare. Neither have a brand name.
The only troubleshooting step I haven't tried is installing and trying on an entirely separate system.

[brentil]

I neglected to mention I tried on two separate accounts, one of which is devoted to the downloader and the other is a spare. Neither have a brand name.
The only troubleshooting step I haven't tried is installing and trying on an entirely separate system.

I just tried that. I made a copy to another machine and I get the same error. I also tried two different accounts and I get the same error. I have my personal Google account and one just for doing downloads and neither are brands. I updated ffmpeg since it does get loaded and that didn't help. I disabled my PiHole, that didn't help.

I tested moving from username/password to cookies and that works. So something is definitely wrong in the user/pass authentication process.

[Roasty-Float]

I tested moving from username/password to cookies and that works. So something is definitely wrong in the user/pass authentication process.

Just repeated this on my system and this is correct. With cookies passed everything works as expected. This is an OK workaround on a singular system/network, but would be tiresome if you carry your downloading system around with you.
For those of you who, like me, had no idea up onto this point passing cookies was an option the readme lays out the basics. Get the addon for your browser, login to your YT account, download the cookies via the addon, then pass the cookie file to the downloader with the '--cookies' option. There's likely a better/more secure method, but that worked for me on my spare account.

[Inginn]

Same issue fixed with cookies.txt
Had to use a addon for chrome to export it (dont know where Arch stores it).
Thanks for the work around.

[Poilaucul]

@Inginn what addon did you use?

[Codingale]

@Poilaucul they probably used this one or at least that's what I used.

Anyways, using the cookies fixed the issue, recaptcha issue maybe? Not really sure...

[Mikeltxo15]

The workaround using cookies.txt worked for me as well. I used cookies.txt for firefox

[Poilaucul]

Using https://chrome.google.com/webstore/detail/cookiestxt/njabckikapfpffapmjgojcnbfjonfjfg worked for me as well, the error

WARNING: unable to log in: HTTP Error 400: Bad Request

is still present but streamed videos are showing up marked as watched in my youtube history.

[brentil]

Using https://chrome.google.com/webstore/detail/cookiestxt/njabckikapfpffapmjgojcnbfjonfjfg worked for me as well, the error

WARNING: unable to log in: HTTP Error 400: Bad Request

is still present but streamed videos are showing up marked as watched in my youtube history.

Did you leave the username/password options in your command line? If you did that will cause it, you only use cookies by themselves.

[kvorobyov]

This workaround with cookies worked for me either, but is it possible to implement native authorization with login and password?

[Shigeto1]

with correct username and password
[youtube:playlist] Downloading login page [youtube:playlist] Looking up account info [youtube:playlist] Logging in WARNING: Unable to log in: HTTP Error 400: Bad Request [youtube:playlist] PLFx03tuShoP9t3u3xzotMMD480_gjncHc: Downloading webpage ERROR: This playlist is private, use --username or --netrc to access it.

with cookies file
[youtube:playlist] PLFx03tuShoP9t3u3xzotMMD480_gjncHc: Downloading webpage ERROR: Unable to download webpage: HTTP Error 400: Bad Request (caused by HTTPError()); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type youtube-dl -U to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

latest version 2019.07.02. clearly an issue with youtube's new login page changes. dealt with the same issue using rclone authentication. why has this not been addressed?