Closed Slinky-Wrangle-Punch closed 2 years ago
This seems to be affecting my instance (invidious.kavin.rocks
) as well, the issue is that invidious adds an ?local=true
to the URL, thus breaking it.
The issue was introduced 11 days ago in https://github.com/iv-org/invidious/commit/0cb442d40ece54b40da1f8415d874c18a1f7f9b5.
The problematic line is here: https://github.com/iv-org/invidious/blob/28ca5b2b57fad510ed3f877bb6662b095e3c41c1/assets/js/player.js#L46
I'm don't think lines https://github.com/iv-org/invidious/blob/28ca5b2b57fad510ed3f877bb6662b095e3c41c1/assets/js/player.js#L44-L49
are necessary, I fail to understand why ?local=true
is being added to /videoplayback
urls.
The Top feed has been removed from Invidious. It relied on YouTube ratings and those are not public anymore.
The Popular feed is the latest video from the most subscribed to channels on the instance, so if there are no subscriptions the feed will be empty.
local=true was always there for proxy hls urls. This change just made it added in the javascript instead of forced in the html template. The actual proxied video url is exactly the same as before, which you can see in the original code: https://github.com/iv-org/invidious/pull/1552/files#diff-40d54e3a4c029ba0f4b05c01bc3e2cd7d4c0763195c34ecf17335a1a22846858L7
The previous code always had local=true in the hls use case hardcoded.
What is the actual specific error when it calls that api? Do you have some har capture or something?
It's also added in the hls playlist url as well https://github.com/iv-org/invidious/blob/master/src/invidious.cr#L3328
The problem is that it generates broken URLs, which creates 400s.
The issue is that the string is incorrectly added.
The problem is that it creates a URL like this:
/videoplayback?param=more?local=true
Hi,
I looked into the change and this should not be happening for /videoplayback. I tried with the latest master and did not see this issue. If you look at the original codes, for the call to hls_variant in the html template also had ?local=true.
But the videoplayback call will not have the question mark issue. The reason is that the call to the hls_playlist api already puts &local=true on the end, so the frontend javascript will not run.
for OP: It seems more like your issue is related to your CSP problem. You enabled https_only but docker doesn't provide that, so maybe your proxy config is not correct?
for FireMasterK: I tested your instance with both failfox and chrome and I was able to play a livestream at least for a short segment. (there are other reasons that livestream always breaks after a minute that are unrelated to this)
I don't understand. Are you using an unusual browser or addons for this?
Can you confirm the response returned by the hls_manifest api?
I don't understand. Are you using an unusual browser or addons for this?
I'm using brave nightly on windows 10, nothing that should affect this... I'm able to reproduce this even on Bromite on Android.
This bug appears to be only reproducible when logged in, I can't reproduce this in incognito.
Can you confirm the response returned by the hls_manifest api?
I'm not sure what you mean, this is a dash stream?
Hi,
I understand now the issue is affecting dash playback not hls streams. This did cause ?local=true to be added to the dash playback url.
But, this did not cause the issue with your instance. It appears that your server may be having poor server health for this api. If you check by using the web developer tools to retry the request with removing the ?local=true, you will see that it still fails. You can also check by rebooting your docker and likely it will work regardless of local=true after the restart.
I will still create a PR to remove this local=true in this case, because it is not necessary here, but this likely won't help your issue.
When I remove ?local=true
it seems to work fine, this is because URLs can't have multiple query strings.
Yes, creating a PR should fix it (unless I'm missing something).
I am running into the same issue as the OP. I am running an docker-compose instance on my (home) server but without any proxying (will be added once running). I am greeted with the empty page with the search bar and when I search it loads indefinitely (timeout? - docker logs do not show anything). I am not adding any CSP or anything as there is no webserver in between (calling by ip:3000). The CSP is added by invidious. However I am not sure it that is the issue...
This issue has been automatically marked as stale and will be closed in 30 days because it has not had recent activity and is much likely outdated. If you think this issue is still relevant and applicable, you just have to post a comment and it will be unmarked.
Is this issue still present?
Closing due to the lack of replies.
I just installed invidious using Docker. I use traefik as the reverse proxy for all my docker containers. Obeying the README I set
https_only: true
domain: tube.mydomain.com
andexternal_port: 443
The setup was easy and now I can watch videos on my own instance at tube.mydomain.com. But I do have two problems.The feed/popular and feed/top are empty, but the the feed/trending does show videos. I cannot find any errors in the docker logs or the browser console regarding this.
If I want to proxy the videos or use dash (which uses proxy AFAIK) the videos do not play and the the banner
The media could not be loaded, either because the server or network failed or because the format is not supported.
occurs.For this I found some errors in the browser console:
GET https://tube.mydomain.com/videoplayback?expire=160773[...]
has400 Bad Request
as statusVIDEOJS: ERROR: (CODE:4 MEDIA_ERR_SRC_NOT_SUPPORTED) The media could not be loaded, either because the server or network failed or because the format is not supported.
Content Security Policy: The page’s settings blocked the loading of a resource at eval (“script-src”).
Any ideas what's wrong? Did I miss any configurations hints from the README?