mirror of
https://github.com/imputnet/cobalt.git
synced 2026-07-17 12:32:26 -05:00
[GH-ISSUE #551] [FIXED] YouTube is sometimes unreachable because of A/B testing of forced log in #4684
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @wukko on GitHub (Jun 7, 2024).
Original GitHub issue: https://github.com/imputnet/cobalt/issues/551
innertube returns "Sign in to confirm you’re not a bot. This helps protect our community. Learn more" instead of video info or regular errors.
cobalt may sometimes not be able to get the video, especially on larger instances (such as main one). if that happens, it'll show you an appropriate error that links to this issue:

related issue threads in repos of other projects:
FIXED:
@dumbmoron implemented support for OAuth2! main instance (cobalt.tools) is back to being able to download youtube videos (so far).
if you host a cobalt instance, you can generate your own token by running
npm run token:youtubein local cobalt repo folder. please don't use your personal google account. it might get banned, restricted, or rate limited.@kane50613 commented on GitHub (Jun 7, 2024):
My YouTube alt account got blocked when I used the cookie.
When I play a video, it always shows "Video unavailable. This content isn’t available." Changing the IP doesn't help.
@wukko commented on GitHub (Jun 7, 2024):
this is exactly what i mean! using user cookies WILL cause issues. this is why using dummy accounts is not a good option, they will quickly run out.
@wukko commented on GitHub (Jun 7, 2024):
support for youtube cookies was added to cobalt in
f6632e2d61, but please don't use your main account cookiesmain instance seems to be fine for now, but it's unknown how long it'll last. we shall see and find out
@wukko commented on GitHub (Jun 7, 2024):
the dummy account cookie already got nuked omfg
update: you need to refresh the cookie every few minutes. it's best to not use it at all and instead use a different authentication method
@00-kat commented on GitHub (Jun 7, 2024):
From what I remember,
Dummy/throwaway accounts are a stupid idea unless you happen to have unlimited cash to burn on burner phone numbers.
(Just letting you know in case you don't already)
@wukko commented on GitHub (Jun 7, 2024):
i do know like no other lol
@wukko commented on GitHub (Jun 7, 2024):
that's what cobalt is for, along with content creation and teaching
@unknownsrc commented on GitHub (Jun 7, 2024):
My Cobalt fork (the only change I made is using
YTSTUDIO_ANDROIDinstead ofWEB) still works. The number of users using Cobalt might be causing YouTube to be upset, but I don't know. It's worth a try, I guess.@alectrocute commented on GitHub (Jun 7, 2024):
Would using a Premium-enabled YouTube dummy account have the same limitations?
@Jacherr commented on GitHub (Jun 7, 2024):
The only way I see a public-facing production instance continuing to work at scale for YouTube video downloading is if Cobalt asks the user to sign in with a Google account prior to downloading. It can then use that account to download the content. Definitely not ideal though, especially for the API..
@Miner11github commented on GitHub (Jun 7, 2024):
Thanks YouTube, you guys really know what you're doing.
@Tintin232 commented on GitHub (Jun 7, 2024):
Wukko, will you be able to get this fixed? 🥺
@alectrocute commented on GitHub (Jun 7, 2024):
I'm actually thankful this broke Discord music bots, as it'll surely bring a lot of mainstream attention to this issue. Fingers crossed.
@2shiraz commented on GitHub (Jun 7, 2024):
Same, I own some YouTube downloader Sites, 4-5 million monthly users and I am losing my mind rn!!
@IoreEroi commented on GitHub (Jun 7, 2024):
The Maki Bot is working Idk how but it is
@alectrocute commented on GitHub (Jun 7, 2024):
Probably just haven't been banned (yet). Luck of the draw?
@2shiraz commented on GitHub (Jun 7, 2024):
That is a great idea. Someone email him the situation
@Mazedotexe commented on GitHub (Jun 7, 2024):
9 hours ago? Wow, that's recent! I wonder how long this has been an issue before that...
And ihatespawn on #555 just mentioned this issue 15 minutes ago...
@wukko commented on GitHub (Jun 8, 2024):
pretty sure he funded an alternative youtube frontend app for android, it affects him directly
@PDL2CGamejolt commented on GitHub (Jun 8, 2024):
OH FOR CRYING OUT LOUD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAa
@DexrnZacAttack commented on GitHub (Jun 8, 2024):
I hope this doesn't make it out of A/B lmfao
Surprisingly, the custom self-hosted music bot that is used in a server I am active in works just fine at the moment, as well as YT-DLP on my machine, it seems neither I or the bot server have been shoved into that A/B testing shit.
@00-kat commented on GitHub (Jun 8, 2024):
(Replying to Mazedotexe) YT-DLP has the oldest issue, at 3 days ago. I however only noticed this issue since yesterday, so maybe YouTube made the IP limit stricter or something sometime in the middle.
Oh and here's every other issue I've found in case you're interested: Piped (1 day), YT-DLP (3 days), Newpipe (17 hours), Invidious (1 day). This issue and YT-DLP's seems to be the most active out of the bunch.
@Zue5s commented on GitHub (Jun 8, 2024):
I propose a solution:
A client that intercepts incoming data from youtube's servers to the device and uses the client's own encoder to make its own video file
idk if this is possible though
edit: this proposal is a client that utilizes the device's own account to access the youtube servers, so not a web based thing
@00-kat commented on GitHub (Jun 8, 2024):
Doesn't YouTube send video files though (in the googlevideo.com domain IIRC)? So I'm not sure what you can intercept and encode.
@Zue5s commented on GitHub (Jun 8, 2024):
looking at the stats for nerds, you can see all the different codec and rate information that the video has, maybe a client that instead of decoding and playing the youtube video data received, it turns it into a file
@00-kat commented on GitHub (Jun 8, 2024):
Just like ffprobe...? You can easily get that data from a file too.
I'm pretty sure the YouTube data received is in the form of a URL to a video. BRB while I grab an example link.
@Zue5s commented on GitHub (Jun 8, 2024):
well a browser doesn't play a video only using a URL, the URL is an address to a point of data access (you guys know this which makes me look stupid) which the browser accesses to get the video data needed just like opening a regular file, and my proposal is taking said video data, not codec information or URL
@00-kat commented on GitHub (Jun 8, 2024):
Interesting idea, but how can you access the video data if YouTube won't return it? I don't know how the block works but I'd assume that YouTube simply doesn't return the video, or a URL to the video, or anything like that. Perhaps it's possible though.
@Zue5s commented on GitHub (Jun 8, 2024):
@00-kat commented on GitHub (Jun 8, 2024):
OH you mean grabbing the result from the browser instead of requesting the data itself? That sounds like a really smart idea actually.
@wukko commented on GitHub (Jun 8, 2024):
have yall heard of cors
@Zue5s commented on GitHub (Jun 8, 2024):
much like recording the screen playing youtube video, but more direct
@00-kat commented on GitHub (Jun 8, 2024):
Actually I just remembered, someone over in the YT-DLP issue says this happens for the YouTube website too, so I don't think that would work. (Edit: I think it was saying that it only happened on the YouTube website after you had been IP banned due to using something else... not sure since I can't find the comment again (perhaps it wasn't on the yt-dlp issue))
Nope, BRB
@Zue5s commented on GitHub (Jun 8, 2024):
the only weakness of my idea is: trackers. Someone at youtube who saw this issue could implement a tracker, that tracks client activity, stopping data sending when detecting my proposal client thing. and since youtube video data aren't sent in one big packet like downloads, trackers are a BIG no no
@00-kat commented on GitHub (Jun 8, 2024):
I don't think that's likely
How might they be able to detect something running on your local device yoinking packets from your browser or something? I don't think it would be possible to detect it, although I might be wrong.
@Zue5s commented on GitHub (Jun 8, 2024):
i thought maybe something that is a part of the browser's code, but i realised that would be damn stupid
@00-kat commented on GitHub (Jun 8, 2024):
I'm not sure if you mean code in Chromium that detects this behaviour made by YouTube, or if you mean an extension that would intercept packets and do what your idea proposes.
If the first: absurd idea and that would effectively require banning Firefox users LOL
If the second: would be kind of easy to block on Chromium based browsers, since they report every extension to the website, however as long as the extension doesn't do something stupid like modifying the DOM, it might work great on Firefox.
Or just something like Wireshark running locally...
@Zue5s commented on GitHub (Jun 8, 2024):
remember when you install an ad blocker and get a notification about how it can access site data? i thought my thing would be similar
@00-kat commented on GitHub (Jun 8, 2024):
BTW is this the right place to discuss that? A browser extension or something is so completely different from this project...
@wukko commented on GitHub (Jun 8, 2024):
@dumbmoron implemented support for OAuth2! main instance (cobalt.tools) is back to being able to download youtube videos (so far).
if you host a cobalt instance, you can generate your own token by running
npm run token:youtubein local cobalt repo folder. please don't use your personal google account. it might get banned, restricted, or rate limited.i will close this issue if the sign in problem doesn't come back within next 2 hours :D
@wukko commented on GitHub (Jun 8, 2024):
yep, seems to be all good
@ggtylerr commented on GitHub (Jun 8, 2024):
I'm on Docker, which container should I run this on?