googlevideo.com issues with HTTPS redirect in firefox

[T4eus]

I saw there was a problem with ublock origin blocking pre-fetching

https://github.com/gorhill/uBlock/wiki/Dashboard:-Settings#disable-pre-fetching
https://en.wikipedia.org/wiki/Link_prefetching

If I uncheck "Disable pre-fetching" at ublock origin, whorks fine, with this checked (what is the default), invidio.us didn't work properly

This just occurs at firefox, chrome doesn't have this issue, at least in my testes

this maybe related to #160 and #151

[omarroth]

Would this perhaps be fixed by #153 in combination with proxying video files as well?

[T4eus]

I don't have any idea, why this occur, and even less how to fix this

note:

On Chromium 51 and above (including browsers based on Chromium 51 and above), this setting does not block DNS lookups and preconnections.

maybe this explain why this not affect chrome, but I looked on the code and don't saw those things

[T4eus]

at Ublock Origin sub-reddit

https://www.reddit.com/r/uBlockOrigin/comments/9fvc28/question_invidious_isnt_working_with_disable/

[T4eus]

instance of uncheck "Disable pre-fetching", I can just use this rule
||invidio.us/js/video.min.js$script,first-party

[T4eus]

having the same problem again

[omarroth]

I think I'm going to close this in favor of #160, as it appears to be a duplicate and there is more information available there.

As a workaround until #160 is closed, try disabling Fanboy's Social Blocking and Fanboy's Annoyance List. If that does not fix it, feel free to reopen this. If, after #160 is closed, you are still encountering this issue, again feel free to reopen.

[omarroth]

My mistake. If the workaround mentioned above resolves the issue, then we can close this in favor of #160,

[T4eus]

I think is a problem related to latency, the player may not see the video URL in time, and show a error messenger.

UBO maybe just make firefox less tolerant with the latency for prevent pre-fetch.

is this what I think, because when I get error and look to the source code, the video is there, and when reopen on another tab the video plays.

[T4eus]

I think, I finally realize whats occuring at all.

This isn't related to UBO (but may this interfere in some way because in my tests looks that when using UBO have more chances to this occur).

Using network monitor I noted that when I get the connection to googlevideo.com this is primary made using HTTP, and later redirected to HTTPS.

I also noted that googlevideo.com dosen't works without a HTTPS connection.

Well, I imagine invidio.us made connections using HTTP and the browser redirects to HTTPS, but sometimes this don't occurs in time for the player, and get the error.

Sometimes interations like open the video on other tab makes the video works (disable prefetch on UBO maybe have this effect, because of this I proposed this relation, at start).

This is also why I don't have problems with the firefox default player, this player wait the HTTP-to-HTTPS redirect.

As a temporary fix (and as a way to test) I'm using HTTPS everywhere.
EDIT: didn't help as expected

May this occurs to me, because the excessive latency I have with in videos (200ms).

[T4eus]

[omarroth]

That's interesting. As far as I know Invidious uses HTTPS for all resources it serves. What happens if you try to access video link directly? You can append &raw=1 to the watch URL to redirect.

[T4eus]

That's interesting. As far as I know Invidious uses HTTPS for all resources it serves. What happens if you try to access video link directly? You can append &raw=1 to the watch URL to redirect.

works fine, but I undertand why

[T4eus]

looks this:

1. invidio.us send my a link like this, https://r6---sn-ab5szn7k.googlevideo.com/
2. who redirect me to this, https://r2---sn-cg51pauxax-28ie.googlevideo.com/
3. and finally this, https://r6---sn-bg0e7n7r.googlevideo.com/

all diferrent URL, this may because invidio.us generate a link based on american region, but I'm outside america.

googlevideos take me to a different server, and the player can't follow this.

in some time of this process the connection is HTTP, as firefox report in the network monitor

[github-actions]

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.