[Bug]: When falling back to an Invidious instance to get videos metadata, videos still won’t load

hollownights commented 1 year ago

Guidelines

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

Describe the bug

When “Preferred API backend: Local API” is set, “Revert to non-preferred backend on failure” is enabled and “Proxy Videos Through Invidious” is disabled, FreeTube gets itself in a conundrum: when it can’t directly get info (through the local API) on a channel or a video for any reason – but specially for our case here when the user is geoblocked – it fallbacks to an Invidious instance to get metadata and, while most of the time does get it by doing so, the user still won’t be able to watch the video they want to watch. Why? Because FreeTube got the video metadata through an Invidious instance, but with those settings the video isn’t being proxied through said instance and the user’s connection – that is blocked by YouTube – is being used to download the video, which just doesn’t works.

The solution? I think the simplest solution right now is to, when falling back to an Invidious instance/API, also proxy the video through the Invidious instance in use.

Expected Behavior

If an user can't get a channel or a video metadata through the local API and FreeTube falls back to Invidious, FreeTube should also proxy the connection/video download through Invidious.

Issue Labels

API issue, content not loading, inconsistent behavior, usability issue

FreeTube Version

v0.18.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

No response

Nightly Build

[ ] I have encountered this bug in the latest nightly build.

efb4f5ff-1298-471a-8973-3d47447115dc commented 1 year ago

would like to have examples of videos so i can understand what u mean. Please provide urls

hollownights commented 1 year ago

I don't want to promote any of these people, so I will just leave a link to a paste with links to their channels: https://bin.infini.fr/?7edf741eccf68a19#A1JEp6VBMs5s28D6Kh6L1k9xYSPsLS18ZJdS1LzBTAWA

Try opening in FreeTube and in the browser those channels, subscribing to them (in FreeTube) and playing their videos. After that, try opening in NewPipe the same channels and videos that you couldn't play in FreeTube and/or in the browser.

efb4f5ff-1298-471a-8973-3d47447115dc commented 1 year ago

Ok looked more into this:

First of all this is all expected behavior because if u go to YT or IV for that matter u are not able to load the video
Asking that FT should also proxy the connection/video download through Invidious if Local API falls back to IV is more like a feature request because all of this is expected behavior it cannot be considered a bug.
We will never force proxy through IV when falling back to IV because that would increase the load on the IV servers allot thats why the user has to explicitly enable it themself. This is also the case if u go to any IV instance.

Maybe there are other things that can be done against this but IMO its better to open up a discussion.

hollownights commented 1 year ago

Ok looked more into this:

@efb4f5ff-1298-471a-8973-3d47447115dc #3766

FreeTubeApp / FreeTube