Very slow video loading

[zrose584]

Even after waiting >1min not even the first segment gets loaded. I think doing a manual page reload helps, but even then one often has to wait ~10-20s for the first 10s (or so) to finally be loaded. After that, the playback often gets stale again. It's not really usable that way..

On the official frontend, the same video loads just fine (and nearly instantly).

I also noticed that sometimes the entire ~20min video gets loaded, even though I have paused it on 00:10. This seems wrong.

I saw this explanation: #94 (comment)
But I wonder if that's all, why is there such latency in the first place? The official frontend doesn't seem to have it.

Also, even after I switch to "native player", the videos often take very long to load. (Both on chrome and on firefox, I think)

Are we really using the exact same requests as the normal frontend? Maybe we use some rarely used resource, and thus it's not cached on google's servers?

[j4ln]

Noticed this same behavior over the last few weeks but it's slowly starting to get worse lately. At first it only happened occasionally and would usually resume as normal after a while. Though this last day it's been pretty bad with not loading the video segments.

[DUOLabs333]

The problem seems to be that this project is (relatively) new, so it doesn't have the optimizations that say, Piped or Invidious, has. (for example, loading videos one at a time instead of in batches).

[user234683]

Is this only with av-merge (qualities other than 360p and 720p)? Or is it normal videos too? It's possible there's some kind of bandwidth restriction. But I definitely notice that it's slower than the frontend. I believed it to be latency due to what I saw in devtools on a cursory examination. But it's possible it's latency on YouTube's end rather than our individual internet connections. It might also have to do with googlevideo redirections being slow with XmlHttpRequest for some reason. Either way I'll see if I can examine it this weekend. If anyone has any clues I'd appreciate it since I've been too busy lately to watch YouTube to see the issue getting worse the past few days.

Sometimes a video will fail to load because of a 403 error (which you can check for by opening one of the sources in a new tab with the devtools open)

I also noticed that sometimes the entire ~20min video gets loaded, even though I have paused it on 00:10. This seems wrong.

The buffering bar in Plyr is buggy. Are you sure the whole video got loaded (i.e. can skip ahead immediately) and not just a Plyr bug?

Also, even after I switch to "native player", the videos often take very long to load.

The native player vs Plyr won't affect actual video loading. Plyr is just UI. The important variable is av-merge vs default browser buffering

[DUOLabs333]

Looking at the Network tab, what seems to happen is that the next bit doesn't load until it reaches near the end, therefore the player has to wait. What would be better is that you continuously load more bits -- maybe always 30s out, without waiting for the current part to finish.

[DUOLabs333]

This can be seen when you pause the player -- instead of trying to load more, it just doesn't.

[DUOLabs333]

Also, how does av-merge work? Does it merge the entire thing before passing it on to the player, or does it just pass in what it already has?

[ghost]

I have the same issue that the videos loads much slower these days compared to last month. I have 250/250 Mbit/s fiber broadband and it has become worst lately (as already mentioned). I've changed the direct link from youtube.com to yewtu.be for better privacy (and loading speed) and the video loads instantly on yewtu.be compared to youtube-local.

[user234683]

Update: I found this invidious issue and this youtube-dl issue recounting the same issue. It looks like invidious is solving it by using the Android client when requesting the URLs. I'll try to have a fix for it this weekend

[DUOLabs333]

It looks like invidious is solving it by using the Android client when requesting the URLs

What user agent do you use now?

[ghost]

Update: I found this invidious issue and this youtube-dl issue recounting the same issue. It looks like invidious is solving it by using the Android client when requesting the URLs. I'll try to have a fix for it this weekend

That's great! I am looking forward to the update :)

What user agent do you use now?

Who? Me? Firefox 93

[DUOLabs333]

Sorry, I was responding to the owner of the repo.

[zrose584]

FWIW, I just realized that my "does not load at all" problem was/is caused by CSP restrictions which occur if one has set proxy_images=False. In that case the XHR-Requests from av-merge.js just get blocked

[user234683]

Temporary workaround before I can make a proper fix:
change line 354 in ./youtube/watch.py
if info['age_restricted'] or info['player_urls_missing']:
to
if True:

Let me know if it works

This will make it always rerequest the URLs using the Android client, by using the code that was originally meant for age restriction bypass. YouTube has added a new cipher that results in throttling instead of 403 errors. They use the n parameter, and the cipher function is much more complicated. Just like the android client doesn't have the usual cipher, it doesn't have this new cipher either.

tfdahlin at pytube made a full parsing solution for the javascript decryption function, which is an alternative to using the Android user-agent (which could get patched in the future) and an alternative to actually executing the javascript code.

[ghost]

Temporary workaround before I can make a proper fix: change line 354 in ./youtube/watch.py if info['age_restricted'] or info['player_urls_missing']: to if True:

Let me know if it works

This will make it always rerequest the URLs using the Android client, by using the code that was originally meant for age restriction bypass. YouTube has added a new cipher that results in throttling instead of 403 errors. They use the n parameter, and the cipher function is much more complicated. Just like the android client doesn't have the usual cipher, it doesn't have this new cipher either.

tfdahlin at pytube made a full parsing solution for the javascript decryption function, which is an alternative to using the Android user-agent (which could get patched in the future) and an alternative to actually executing the javascript code.

That seems to fix the issue! I took some random videos and they loads basically as fast as what yewtu.be does. And when I fast-forwarding from a couple of seconds into the video to maybe 3 minutes in, it loads/buffers very fast too.

[DUOLabs333]

This works perfectly! So wouldn't the fix be just remove the conditional and always call it?

[user234683]

You can remove line 373 to make the workaround work with non-embeddable videos such as this one

[DUOLabs333]

Huh, I tried changing the clientScreen, which didn't work. Didn't know you had to completely remove it.

[Utopiah]

Temporary workaround fixed it for me too. Happened also for few weeks too/

[DUOLabs333]

000501e fixed this issue, so it can be closed now.

[leimath]

When trying to load this video Wendigoon's The American Broadcaster.... It does not load at all. Other videos work fine. Any comments on why/how I can fix this ?

[user234683]

Disable the "Prefer integrated sources" setting.See #129

…

On Mon, 2022-05-02 at 22:44 -0700, leimath wrote: When trying to load this video Wendigoon's The American Broadcaster.... It does not load at all. Other videos work fine. Any comments on why/how I can fix this ? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: < ***@***.***> [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": " #95 (comment) ", "url": " #95 (comment) ", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[user234683]

Closing now that this has been fixed properly