[Bug]: Videos still not playing on v0.22.1

[grizzlybeartist]

Guidelines

• I have encountered this bug in the latest release of FreeTube.
• I have encountered this bug in the official downloads of FreeTube.
• I have searched the issue tracker for open and closed issues that are similar to the bug report I want to file, without success.
• I have searched the documentation for information that matches the description of the bug I want to file, without success.
• This issue contains only one bug.

Describe the bug

Any video clicked on still gives both local and invidious api error, followed by either an entirely blank page or an error message over the thumbnail in the player saying "watch session expired, please log in" (paraphrasing).

Expected Behavior

Videos should play as normal.

Issue Labels

feature stopped working

FreeTube Version

v0.22.1

Operating System Version

Windows 11 Home 23H2

Installation Method

.exe

Primary API used

Local API

Last Known Working FreeTube Version (If Any)

No response

Additional Information

In the last version, this was only happening to videos which contentid flagged. now it's happening to all videos, including ones that worked on previous editions. I've tried both the .exe and the .zip installation methods. I have not tried fully deleting freetube and using a fresh install. Windows Defender and the like have been disabled on my system, so I don't think it's them interfering and damaging/corrupting files either. When testing the nightly build, it instead gave an IP blocked warning, and only allowed me to watch videos once my VPN was disabled. Disabling VPN on the main version did not seem to have any effect. It's not a specific server either, it was any time my VPN was enabled at all regardless of location, and this same bug does not occur when pulling up youtube in browser, nor with any other websites or applications. If it helps any, I'm specifically using Mullvad VPN.

Nightly Build

• I have encountered this bug in the latest nightly build.

[absidue]

That likely means that most Mullvad servers have been flagged by YouTube, in that case you'll either have to keep searching for a server that isn't blocked or try a different VPN provider. Additionally when you say it works in your browser, is that in an incognito window while being logged out of YouTube?

[grizzlybeartist]

That likely means that most Mullvad servers have been flagged by YouTube, in that case you'll either have to keep searching for a server that isn't blocked or try a different VPN provider. Additionally when you say it works in your browser, is that in an incognito window while being logged out of YouTube?

Nope, a tab that's logged in, which is an oversight on my end considering the error message literally says logging in will fix it, lol. When I just tried it in incognito, youtube allowed me to access videos seemingly regardless of server, though I admittedly only tested a handful, not as extensively as when I was trying to get things to work. After searching through for a while I did find a vpn server that allowed me to connect on the nightly build, but I made this post prior to that—probably should have left an update comment about that, my bad. Leaving the thread open for now in case further info is needed

[sleeplessKomodo]

Wow, they're blocking mullvad now? Guess I'm not watching youtube anymore, so long.

[SKlein-1428]

Wow, they're blocking mullvad now? Guess I'm not watching youtube anymore, so long.

FWIW - based on testing with a browser - it's not an outright block, it's a "redirect to the tracking service known as reCAPTCHA v3". They're trying to deanonymize mullvad users via reCAPTCHA or forcing us to sign in.

[CaptainKram]

It is not just mullvad, I'm using proton and getting [BAD_HTTP_STATUS: 403] Potential causes: IP block or streaming URL deciphering failed.

[absidue]

Unfortunately it's a cat and mouse game between YouTube and the people that they actually want to block (the people making too many requests and downloading too much, so as the companies that are mass-downloading videos to train their machine learning algorithms). You are just getting caught in the crossfire as you are using the same VPN IP addresses as them.

[CaptainKram]

Switching the VPN 2 times helped. It seems specific instances are IP blocked.

[ArthurKun21]

Hello

I'm not using VPN and seems like I'm getting hit too

9046edc - Build 5322

bundle-1734663137242.log

[Aragorn-E]

I'm NOT using a VPN, and I also got this error message:

[BAD_HTTP_STATUS: 403] Potential causes: IP block or streaming URL deciphering failed

How do I get around this?

Happens on:
v0.22.1 Beta
v0.22.1-nightly-5335 Beta

[Astaoth]

I get this issue is caused by the use of a blocked network in my case. However, I've no issue when playing the videos from inv.nadeko.net or yewtu.be. Why this doesn't work ? I even can't load the subscription videos when selecting invidious backends.

[absidue]

@Astaoth That's because the instances on the public Invidious instances list had turned off API support (check the API column on https://api.invidious.io), that means you can still use them if you visit their own websites directly but can no longer use them through 3rd party tools like FreeTube.

Edit: looks like it's back again now, was gone for the last few days.

[absidue]

We are looking into it, NewPipe and ReVanced seem to be affected too.

[Astaoth]

@Astaoth That's because the instances on the public Invidious instances list had turned off API support (check the API column on https://api.invidious.io), that means you can still use them if you visit their own websites directly but can no longer use them through 3rd party tools like FreeTube.

Edit: looks like it's back again now, was gone for the last few days.

Oh I see, thanks ! I'll keep the api link in mind the next time this issue happens.

Anyway, got the same problem. Mullvad btw.

About Mullvad, they have few different providers. Maybe the issues are only with some of them and not the others ? I've already seen this with twitch and ProtonVPN, when the traffic is from 31173 (I think it's owned by Mullvad, it's also used by Proton and Nord) there are more traffic restrictions that from others.

[SKlein-1428]

Anyway, got the same problem. Mullvad btw.

About Mullvad, they have few different providers. Maybe the issues are only with some of them and not the others ? I've already seen this with twitch and ProtonVPN, when the traffic is from 31173 (I think it's owned by Mullvad, it's also used by Proton and Nord) there are more traffic restrictions that from others.

Can confirm. Used a server I'm not usually comfortable with for my own reasons and it worked - if anyone's in a similar boat and doesn't want to compromise on their server choices for other activities, you can use the wireguard socks5 multihop to make it so only FreeTube is coming out.

My FreeTube is currently in Manchester, UK, gb-mnc-wg-005 and working while everything else is in Sweden where I like it.

Edit: I didn't do extensive testing so don't take this as gospel, but the ones I tested that were owned by Mullvad failed, the ones they rented from a third party server provider worked.

[CaptainKram]

A wild guess but it might have something to do with secure DNS over https (default being cloudflare). For people without VPN - the cloudflare servers might be unfairly targeted. Check your browser settings for testing if you want to.

[zipfile6209]

I've noticed that this usually only happens to me when starting the app, and that changing the vpn to another server usually solves it, even if the new server at other times also has this problem.

I wonder, could it be that retrieving many feeds with the default method (not rss), is triggering the restrictions?

[Astaoth]

I've noticed that this usually only happens to me when starting the app, and that changing the vpn to another server usually solves it, even if the new server at other times also has this problem.

I wonder, could it be that retrieving many feeds with the default method (not rss), is triggering the restrictions?

That looks like a killswitch issue on your VPN configuration. When switching from a server to an other, without killswitch, you will make a direct internet access.
With a VPN the issue isn't that we can't retrieve feeds, but we can't play videos because it requires an auth, to validate we aren't a bot.

[zipfile6209]

@Astaoth You misunderstood me entirely 🙃

I was not referring to the lapse during the server change (my mullvad killswitch works fine), but to being on another server. Regarding the point, I wonder if feed retrieval implies “this suspicious ip has made too many requests in a short time”, enough to trigger viewing restrictions; also if rss avoids it.

[absidue]

@I-I-IT FreeTube's local API uses YouTube.js, we have been using it a lot longer than anything Invidious related has. e.g. the reason why Invidious instances that use invidious-companion have multiple audio-track support in their own websites, is because of code that we contributed to YouTube.js.

Also the user-agent blocking has nothing to do with FreeTube, we use the API if the instance allows it, we respect the instances maintainers wishes. The user-agent blocking is to combat people that don't respect those wishes and switched to scraping the Invidious webpages when the API got disabled.

Please just sit tight until we figure out a solution, as mentioned in my earlier message above other YouTube projects are affected too (NewPipe, ReVanced, yt-dlp, etc).

[I-I-IT]

@I-I-IT FreeTube's local API uses YouTube.js, we have been using it a lot longer than anything Invidious related has. e.g. the reason why Invidious instances that use invidious-companion have multiple audio-track support in their own websites, is because of code that we contributed to YouTube.js.

Good to know.

Also the user-agent blocking has nothing to do with FreeTube, we use the API if the instance allows it, we respect the instances maintainers wishes. The user-agent blocking is to combat people that don't respect those wishes and switched to scraping the Invidious webpages when the API got disabled.

Oh, I got it!

Please just sit tight until we figure out a solution, as mentioned in my earlier message above other YouTube projects are affected too (NewPipe, ReVanced, yt-dlp, etc).

I really hope a solution is found.

[expyth]

@SKlein-1428 Damn, I wish I knew what you're talking about. I want to continue using Freetube :(

[SKlein-1428]

@SKlein-1428 Damn, I wish I knew what you're talking about. I want to continue using Freetube :(

At risk of going offtopic, hopefully it can stay because it might help others. At least Mullvad users:

https://mullvad.net/en/help/different-entryexit-node-using-wireguard-and-socks5-proxy - I used this guide, but put the resulting proxy information into the "Proxy" area on FreeTube. I picked a rented server in Manchester - I've tried two now and both worked. (Whether a server is rented or owned by mullvad is something included in the server list).

This only works if you use WireGuard as your protocol and it will add an extra hop to your Freetube, but given that YouTube videos are a datastream where ping only really matters for loading the pages it shouldn't be super detrimental (I'm always multihopping so I can't tell any difference to give).

Doing this means I connect to my usual Mullvad servers, and then the proxy routes FreeTube traffic to one that isn't blocked that might be "less private/secure" (in my, subjective, mind) but still better than nothing.