Skip to content
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

Make invidious use HTML5 innertube client if the Android client fails #4549

Closed
wants to merge 1 commit into from

Conversation

techmetx11
Copy link
Contributor

This makes Invidious fallback on the HTML5 client if fetching the streaming data from Android fails.
Fixes the current issue with YouTube returning a "Video Not Available" video on the outdated Android client version that Invidious uses (also makes the code log a warning in case this happens too)

@techmetx11 techmetx11 requested a review from a team as a code owner March 31, 2024 12:59
@techmetx11 techmetx11 requested review from syeopite and removed request for a team March 31, 2024 12:59
@techmetx11 techmetx11 changed the title Workaround: Make invidious use HTML5 innertube client if the Android client fails Make invidious use HTML5 innertube client if the Android client fails Mar 31, 2024
@SamantazFox
Copy link
Member

The problem with WEB/TV clients is that the streams are throttled.
To fix that, we'd have to implement a JS sandbox for the n-function.

It's good as a temporary fix for a small instance, but it can't scale for public instances.

@SamantazFox
Copy link
Member

Still, thanks for the PR ^^

@unixfox
Copy link
Member

unixfox commented Mar 31, 2024

I still think we should fallback to WEB even if we are throttled.

It is better to provide a video feed than having an error.

@SamantazFox
Copy link
Member

I don't know. I thing it's more frustrating to have a video that takes forver to load than a straight out error.

I'm really reconsidering adding some JS parser for the n-function.

@raxod502
Copy link

raxod502 commented Apr 5, 2024

Even if the JS parser isn't added, it might be warranted to allow server administrators to enable fallback to HTML5 streaming. After all, some servers are intended for personal or small-group use, and the tradeoff might be considered superior in those cases. The administrator of the server in question would be best positioned to make that determination, hence my suggestion that this might make sense as a server-side config option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants