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

[xa4hf8]

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.

[iBicha]

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.

[xa4hf8]

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]

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]

Found a related discussion that might be worth monitoring.

yt-dlp/yt-dlp#11868

[sethro2]

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]

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]

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]

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
  • Update: change deployed to latest version for everyone
• 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

[allenwalker3]

I've been getting the same "bot" error message. Sometimes I have to reload the video 5 times to get it to play. I'm on a US residential IP. Started occurring almost a week ago. Version 0.25 Build 0

[iBicha]

I've been getting the same "bot" error message. Sometimes I have to reload the video 5 times to get it to play. I'm on a US residential IP. Started occurring almost a week ago.

Please share the app version
Edit: to be specific, the "Playlet lib" version. This is the version you seeing the side menu, or the info screen

[sethro2]

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

  • Update: change deployed to latest version for everyone

• 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

I watched several videos, performed searches and scrolled several pages.. couldn't get it to break. This tweak you made here seems to be working great!

[allenwalker3]

Haven't had any issues yesterday and today (1/19 - 1/20)

[Artemis6428]

Haven't had any issues yesterday and today (1/19 - 1/20)

same here ^w^

[xa4hf8]

From the QA department... I devised a reliable way to trigger the block by stepping though a list of live streams in rapid sequence. The block would always be triggered on one or more streams within a couple of cycles and progressively expand from that point. I have tested this fix against that list on multiple days with a high traffic public IP and did not encounter the block. I suppose there could be countermeasures in future but right now this patch works in all test cases. Good job sir, and thanks for your service. 🫡🏅

[iBicha]

Looks like we're stable based on the stats as well https://github.com/iBicha/playlet/wiki
Thanks everyone for your help