-
Notifications
You must be signed in to change notification settings - Fork 842
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
[Bug]: BAD_HTTP_STATUS: 403 YouTube watch session expired. Please reopen this video. #5991
Comments
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 |
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: 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. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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. |
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. |
This comment has been minimized.
This comment has been minimized.
Okay so this issue is two things:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I already agreed to it here #5991 (comment) ... |
Ok let me know if you need more information 👍 |
I was just thinking, maybe F5 to refresh the video would be a better implementation, that leaves it up to the user. |
You can already use |
Guidelines
Describe the bug
Using FreeTube connected to invidious.catspeed.cc as the Invidious backend:
Expected Behavior
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
The text was updated successfully, but these errors were encountered: