[Bug]: BAD_HTTP_STATUS: 403 YouTube watch session expired. Please reopen this video.

[mooleshacat]

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

Using FreeTube connected to invidious.catspeed.cc as the Invidious backend:

1. Select any video to watch
2. Either receive playback, or "BAD_HTTP_STATUS: 403 YouTube watch session expired. Please reopen this video."

Expected Behavior

• Expected playback / uninterrupted playback
• I would expect FT to attempt the connection maybe 3-5 times before giving the user the error and asking them to reload.

Issue Labels

content not loading, inconsistent behavior

FreeTube Version

v0.22.0

Operating System Version

Windows 10

Installation Method

.exe

Primary API used

Local API

Last Known Working FreeTube Version (If Any)

No response

Additional Information

Tracking this issue on my gitea https://gitea.catspeed.cc/catspeed-cc/invidious/issues/11

One thing I have noticed, is invidious.catspeed.cc player will retry the XHR request when it receives a 403 and while it may take longer, always plays the video

On FreeTube only is where I get this error, and instead of FreeTube retrying again and getting playback, it just shows the error and forces me to re-open the video.

I would expect FT to attempt the connection maybe 3-5 times before giving the user the error and asking them to reload.

This also affects users who are mid-playback and will get a random 403 which then gives the error asking the user to reload the video. I think FT should try the request over 3-5 times before giving the error so playback is not interrupted.

Nightly Build

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

[mooleshacat]

Please note, this error only occurs with FreeTube.

The invidious web player always retries the XHR request and will eventually get a good response.

This was not an issue before v0.22.0 it only started happening after the release of v0.22.0

[absidue]

Okay so it looks like I forgot to add support for extracting the video expiry time for Invidious, as it's not in any of the API response fields, we probably need to take it from the streaming URL instead. That will make it show the correct error message: [BAD_HTTP_STATUS: 403] Potential causes: IP block or streaming URL deciphering failed

Are you saying that Invidious instances are now expected to automatically fix their servers in a quick enough time that playback can resume? Previously once they were dead they stayed dead for a while, which is why FreeTube is designed to show an error screen when it breaks, because there is no point wasting network requests and the users time if you know it is broken.

[absidue]

The whole reason why FreeTube doesn't retry is that in the past when FreeTube got a 403 from an Invidious instance it meant it was IP blocked and was expected to stay blocked until the instance maintainer fixed it, so it would have had to retry for hours until it would work again.

[absidue]

We can add a retry loop/ignore errors when using the Invidious API for a while, but we definitely shouldn't do it on the local API because it will just result in YouTube extending the IP block for a longer period of time.

[absidue]

Okay so this issue is two things:

• We need to add support to FreeTube for extracting the expiry date from the streaming URLs for Invidious
• We need to add another Invidious specific workaround to FreeTube to make it only show an error message if the error is repeated too many times, but for the local API make it behave normally and show the error as soon as it happens.

[absidue]

I already agreed to it here #5991 (comment) ...

[mooleshacat]

Ok let me know if you need more information 👍

[efb4f5ff-1298-471a-8973-3d47447115dc]

@mooleshacat we changed some thing, please test the latest nightly build and check if the issue is resolved

[Darklesss]

@efb4f5ff-1298-471a-8973-3d47447115dc I'm not the OP, but I came here searching for a solution to the same problem and the nightly build fixed it, thanks.

[DownyDawn]

I tried the latest nightly build 5301 cause of the 403 error and its a big win ! Thanks you guys :D

[github-actions]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[LueKely]

I have also encountered this bug on linux mint but reinstalling the software from Flatpack seems to be the solution for my case