[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]

If you are using 0.22.1 and are experiencing problems please DO NOT COMMENT ANYMORE, repeating things that everyone else has already said and that we have already acknowledged as a problem, is very unhelpful as it makes it a lot harder to keep track of the useful comments (people saying they are experiencing issues with the latest development changes).

[absidue]

@OothecaPickle Your comment seems to have vanished but you mentioned that it broke temporarily for you on the nightlies, but then started working again, did it break again anytime since then?

[SKlein-1428]

@SKlein-1428

you can use the wireguard socks5 multihop to make it so only FreeTube is coming out.

Can you elaborate on this. "make it so only freetube is coming out" sounds like what split tunnelling is meant to achieve. Multihop makes all of your traffic go through the vpn, but twice (different ip's of course). I just want to make sure I'm on the same page.

Mullvad allows you to multihop with a SOCKS5 Proxy, which allows you to split-tunnel in such a way where both things are still going through the VPN but coming out of different exit nodes, so you can find a server that is less likely to get blocked/isn't currently being blocked and use its SOCKS5 settings in FreeTube.

[OothecaPickle]

@OothecaPickle Your comment seems to have vanished but you mentioned that it broke temporarily for you on the nightlies, but then started working again, did it break again anytime since then?

Haven't experienced the error again, will update if I do.

[quuinnn]

Doing the Mullvad Proxy stuff (https://mullvad.net/en/help/socks5-proxy) under settings -> proxy and enabling Fetch Feeds from RSS and disabling Fetch Feeds Automatically under settings -> subscriptions fixed it for me

[CaptainMorgan12]

Freetube v0.22.1 Beta Flatpak Install
Once you switch it to 360p it plays with VPN (Proton), key is to pause it as soon as you open the stream, change resolution to 360p.
Afterwards you can change it to any other resolution setting and it will keep playing as a workaround.

[Vlaaaaaaad]

I was not using a VPN and I had the same issue. It turns out that after I downloaded 30-ish videos using yt-dlp, YouTube flagged/blocked my IP — I could play videos on YouTube fine, but both YouTube embeds on other sites were failing ("please log in to confirm you're not a bot" even though I was logged in) and FreeTube were failing to play videos. I restarted my router (my ISP allocates dynamic IPs) and the problem instantly went away 🙂 That might help some of y'all so I thought I should mention it.

[ACR-Jeff]

Appears changing resolution in the settings to 720p works on my end.

[mateess]

Maybe this issue should be reopened, so people see it's being worked on and don't post duplicate issues? Seems to be much more widespread for the last few days...

[absidue]

It's already pinned at the top of the issue list, it doesn't get more discoverable than that. Unlike other problems in the past people have been surprisingly well behaved this time, duplicate issues have been less of a problem, more just duplicate comments (people some how think that repeating that they are experiencing it on 0.22.1 when everyone else has already said it and we have already acknowledged it and provided a potential fix, is going to have any effect other than just being annoying).

Ideally we would lock the issue to prevent the spam, but we still want to hear from the people that claim they are still experiencing problems on the latest nightly, as those comments are actually useful.

[liammcsh2008]

Temporary Solution: I changed it to Legacy Formats and the video plays as normal.
Edit: I am using UrbanVPN, and it fixed it too. I set my location to any Central American Country