Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Video load error: “Failed to load / confirm you’re not a bot” #479

Open
xa4hf8 opened this issue Oct 21, 2024 · 8 comments
Open

Video load error: “Failed to load / confirm you’re not a bot” #479

xa4hf8 opened this issue Oct 21, 2024 · 8 comments
Labels
bug Something isn't working

Comments

@xa4hf8
Copy link

xa4hf8 commented Oct 21, 2024

When my device is connected through a shared public proxy (VPN), YouTube access is randomly restricted, but the blocking of specific items is inconsistent: some clips will work but may stop working if replayed, and items that do not play might begin to work several hours later. But the issue does not occur with the official Roku YouTube client, even when no YouTube account was configured on the device.

Roku

@iBicha
Copy link
Owner

iBicha commented Oct 24, 2024

Thanks for reporting - when we fetch video data, we don't perfectly mimic an official client, so there's probably a threshold between "a lot of traffic coming from the same ip" and "this payload is missing a few fields, or have some values that don't make sense" which would trigger this error message.
I'll keep an eye on this issue, but honestly without a solid method to reproduce it, it's going to be hard to find a fix.

@iBicha iBicha added the bug Something isn't working label Oct 24, 2024
@xa4hf8
Copy link
Author

xa4hf8 commented Nov 24, 2024

without a solid method to reproduce it, it's going to be hard to find a fix

I have conducted some additional research on this issue and found that it occurs frequently on ProtonVPN when a channel is bookmarked and recent uploads for the channel are played in sequence or repeated. The issue is usually reproducible once blocking begins. After some hours (or the next day), the block is often reset.

@iBicha
Copy link
Owner

iBicha commented Nov 26, 2024

Thanks for confirming. The only thing I can think of to possibly improve this, is to implement poToken (Point of origin token) somehow https://github.com/iv-org/youtube-trusted-session-generator. It might help, but usually public VPNs are always going to be subject to these blocks, because unusual amount of YouTube traffic is coming from the same IP address, which will be detected as bot traffic

@xa4hf8
Copy link
Author

xa4hf8 commented Dec 27, 2024

Found a related discussion that might be worth monitoring.

yt-dlp/yt-dlp#11868

@sethro2
Copy link

sethro2 commented Jan 3, 2025

The issue started a few weeks ago but was intermittent. The issue would clear by the next day. However, the problem started to occur after watching several videos in a row say, 8 videos... and clear the following day.

As of yesterday, I cannot watch any video without getting the "confirm you are not a not" message.

The thread that Xa4hf8 linked above is interesting. Makes me think Youtube has new measures in place.

@sethro2
Copy link

sethro2 commented Jan 17, 2025

Just passing this along as an observation. Some days after my posting above, I was able to watch videos again without getting the 'bot screen of death'. However, noticed after using search to find videos - I got the error. The next day, watched a few videos then tried searching again and paged through a some results - got the error. Next day, I searched but did not advance beyond the first page of search results and all was fine.

@xa4hf8
Copy link
Author

xa4hf8 commented Jan 18, 2025

An interesting curiosity -- there have been reports that watching a YouTube video in a web browser unlocked it for alternative clients on the same device. Obviously we cant do that with Playlet but there may be similar work-arounds. Here are some other YouTube clients claiming or testing a fix:

ytptube · It fails with a 403 error when downloading in audio only mode-fixed
https://github.com/arabcoders/ytptube/issues/160

pipepipe · As of today, the only situation that triggers 403 is switching network after fetching stream detail
https://github.com/InfinityLoop1308/PipePipe/issues/613

harmony-music · Fixed now, please check new version
https://github.com/anandnet/Harmony-Music/issues/392

@iBicha
Copy link
Owner

iBicha commented Jan 18, 2025

Thanks everyone for sharing your findings.

I've been trying to poke at this problem, and after testing I found that just adding a valid visitor data to payloads when loading video feeds helps A LOT.

I would like to confirm that the changes I made here #545 help improve things if you would like to help with that, by testing and reporting back, I'd appreciate it

  • This change is not released in latest yet, it is available in Canary https://github.com/iBicha/playlet/releases/tag/canary
  • I don't believe this is a fix, it's a bandaid that, if it works, it will buy some time, days or weeks
  • My goal is not to "fix" this error, but see if it helps reduce the amount of errors you see
  • Please avoid VPNs or any hight traffic IP address, because that will not help confirm anything
    • I'm not saying don't use VPNs, I'm saying if you are testing and reporting back, please stick to residential IPs, so that it would appear like normal traffic, not some sort of data center. This is to avoid false-positives (either way, please be specific when reporting)

Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants