Buffering when playing

[Gythion]

Context

Please provide any relevant information about your setup

• Add-on Version: 6.8.17 matrix
• Kodi Version: 19.0
• Kodi GUI Language: Ita
• Operating System: Win10
• Operating System Language: Ita

---

Expected Behavior

Normally playing without buffering

---

Current Behavior

Buffering at almost every played video in FHD or HD

Log

t.ly/9ItW

---

Additional Information

How about? It is already several months that there is this problem. I use the official YT app in FireStick, and no buffering.

---

[jonisb]

Update the plugin to 6.8.18.alpha1 as it seems to work much better with the buffering

163 issue is related to this

[Rialtho-the-Magnificent]

I have the same. More and more videos show this behaviour. Have tried to reduce resolution, but even with 480 setting I still get buffering. Also, when stopping the video and restarting it, it takes several attempts before it finally decides to play normal. Some videos however take more than 5 times and that is too much for me. The logs show nothing that might explain what is going on.

[probonopd]

Same here. The issue seems to persist in 6.8.18.alpha1, at least with some videos. Are we getting throttled?

[terxw]

Buffering also in 6.8.18.alpha1 Edit: 6.8.18.alpha2 is working OK, no bufering

[ghost]

Happens in Linux too. Not always, occasionally.

[Rialtho-the-Magnificent]

I use it on a PI 3b with OSMC but the buffering problem is getting worse and worser. Started couple of weeks ago. I guess it is something that Google did and it is related to the amount of ads that are suppose to be shown in front of the selected videos, especially when the video is new there is a time period (which varies per channel) where ads are non-skippable if viewed via other means, like the YT app on a tablet or phone. Older videos have this problem also, but one or two times stopping and starting the video solves the problem.

[arncor]

I use it on a PI 3b with OSMC but the buffering problem is getting worse and worser. Started couple of weeks ago. I guess it is something that Google did and it is related to the amount of ads that are suppose to be shown in front of the selected videos, especially when the video is new there is a time period (which varies per channel) where ads are non-skippable if viewed via other means, like the YT app on a tablet or phone. Older videos have this problem also, but one or two times stopping and starting the video solves the problem.

interesting comment, but I haven't got any buffering issues when I watch YouTube using the Android Newpipe app (which bans ads) or on the computer using Firefox + uBlock Origin (which also bans ads). It seems to be really specific to Kodi/YouTube_addon/InputStream_adaptative.

PS : I also got buffering issues on Raspberry Pi 4, Kodi 18.7, YouTube 6.8.17, InputStream Adaptative 2.4.4. When buffering, I noticed the network download speed settles around 70-90KB/s (out of a 300Mbps connexion). When NOT buffering, the network usage is different, with occasionnal spikes of hundreds of KB/s and 0KB/s in between.

Also the YouTube addon cannot allow more than 100MB (default is 70MB) of cache, which I think is pretty low. Cache settings in advancedsettings.xml file such as buffermode, memorysize and readfactor doesn't seem to apply to video played with the youtbe addon.

PS2 : I mostly play Youtube videos on Kodi using my phone+Newpipe > "play with kodi" option. So the URL sent to kodi is done via newpipe, maybe it has an influence...

[Rialtho-the-Magnificent]

Thanks for the additional info. I also have no problems running adfree YT on my PC (using an modified etc\hosts file). But the buffering seems to be sort of random. Yesterday, I also had a 403 error (according to the log file of kodi) on a number of YT videos that are mainly music. Not sure if this is related. And then there are the videos that give the sad face when selected. That usually goes away after several hours. I still believe that has something to do with the non-skippable adds that Google wants to serve as hours later the video does play normal (or also has buffering issues, and you have to retry several times). (all using 6.8.18...)

[pitsi]

If @anxdpanic is reading this, can you please add the development version of the addon in your testing repo? It will help us who use the repo get the newest releases and do the testing early. Right now it hosts 6.8.16, which is older than the one in the main kodi repo. Thank you in advance.

[probonopd]

Still getting the buffering issue with plugin.video.youtube-6.8.18.alpha2.zip, e.g., on this video: https://www.youtube.com/watch?v=a3oQy6v3MrA

[probonopd]

Here is a workaround that works reliably around this issue (while waiting for a proper fix):

1. Install and configure https://github.com/lekma/plugin.video.invidious/ (use release 0.5.7 if you are on a Python 2 based system). Configure it to use vid.puffyan.us as the instance
2. In plugin.video.youtube, add a "Play with Invidious" context menu:

At the end of plugin.video.youtube/resources/lib/youtube_plugin/youtube/helper/yt_context_menu.py, add:

def append_play_with_invidious(context_menu, provider, context, video_id):
    context_menu.append(("Play with Invidious", 'PlayMedia(plugin://plugin.video.invidious/?action=video&videoId=%s)' % video_id))

In plugin.video.youtube/resources/lib/youtube_plugin/youtube/helper/utils.py, add directly above the line def update_play_info(provider, context, video_id, video_item, video_stream, use_play_data=True):

        yt_context_menu.append_play_with_invidious(context_menu, provider, context, video_id)

Restart Kodi (or deactivate and activate the YouTube addon) for the changes to take effect.

Now select "Play with Invidious" from the context menu to enjoy stutter-free instant playback.

Does anyone know how to make "Play with Invidious" the default action when a video is clicked?

---

I haven't investigated how Invidious generates the information that ends up in

• https://vid.puffyan.us/api/manifest/dash/id/aqz-KE-bpKQ
• https://vid.puffyan.us/api/v1/videos/aqz-KE-bpKQ?&pretty=1

but it seems it is golden.

[tssajo]

@probonopd Unfortunately, the workaround you posted doesn't work for me. In fact, Invidious cannot play a single video on my Raspberry Pi 3 Model B Plus running LibreELEC. I managed to install plugin.video.invidious to v0.6.6 from Lekma's repository, from here: https://github.com/lekma/repository.lekma/

Here is what gets logged:

2021-10-10 23:36:57.971 T:1235366784  NOTICE: [plugin.video.invidious] request.url: https://invidious.snopyta.org/api/v1/videos/tflC9c4KhFo
2021-10-10 23:37:00.642 T:1147577216  NOTICE: [plugin.video.invidious] video.url: https://invidious.snopyta.org/api/manifest/dash/id/tflC9c4KhFo
2021-10-10 23:37:01.582 T:1937289280  NOTICE: VideoPlayer::OpenFile: plugin://plugin.video.invidious/?action=video&videoId=tflC9c4KhFo
2021-10-10 23:37:01.590 T:1218581376  NOTICE: Creating InputStream
2021-10-10 23:37:01.677 T:1218581376   ERROR: CCurlFile::FillBuffer - Failed: HTTP returned error 403
2021-10-10 23:37:01.677 T:1218581376   ERROR: CCurlFile::Open failed with code 403 for https://invidious.snopyta.org/api/manifest/dash/id/tflC9c4KhFo:
2021-10-10 23:37:01.677 T:1218581376   ERROR: AddOnLog: InputStream Adaptive: Cannot download https://invidious.snopyta.org/api/manifest/dash/id/tflC9c4KhFo
2021-10-10 23:37:01.677 T:1218581376   ERROR: AddOnLog: InputStream Adaptive: Could not open / parse mpdURL (https://invidious.snopyta.org/api/manifest/dash/id/tflC9c4KhFo)
2021-10-10 23:37:01.678 T:1218581376   ERROR: CVideoPlayer::OpenInputStream - error opening [plugin://plugin.video.invidious/?action=video&videoId=tflC9c4KhFo]
2021-10-10 23:37:01.678 T:1218581376  NOTICE: CVideoPlayer::OnExit()
2021-10-10 23:37:01.794 T:1937289280  NOTICE: CVideoPlayer::CloseFile()
2021-10-10 23:37:01.794 T:1937289280  NOTICE: VideoPlayer: waiting for threads to exit
2021-10-10 23:37:01.794 T:1937289280  NOTICE: VideoPlayer: finished waiting

As you can see, Invidious receives 403 HTTP errors. But why? Does anyone have any idea on how to solve this?

[probonopd]

Try vid.puffyan.us as the instance instead of invidious.snopyta.org. snopyta.org seemingly does not allow API access.

[tssajo]

@probonopd Thanks for the tip! But I am in Europe. Anyhow, I just checked the URL with my PC and it downloaded the file just fine, this one: https://invidious.snopyta.org/api/manifest/dash/id/tflC9c4KhFo So I didn't get a 403 error on my PC. I experiment with Curl on my Raspberry Pi. If I find a solution I will post it here for others.

[tssajo]

OK, Invidious finally works. Both vid.puffyan.us and invidious.namazso.eu works fine. I picked the latter one from this list https://redirect.invidious.io/watch?v=dMRH96Ew5G4

[bzarky]

I am having the same playback issues as well and it's worse after the 19.2 kodi update.

Here's my debug log trying to play a youtube video. System is Ubuntu 21.04 on am64

kodi.log

[RNavega]

Does anyone know how to make "Play with Invidious" the default action when a video is clicked?

@probonopd

1. When a video item is created, it uses the /play/video_id=... route, created in here:
   https://github.com/anxdpanic/plugin.video.youtube/blob/36e037518bbb14a06a4928c9dd5b77baaa70c3d3/resources/lib/youtube_plugin/youtube/helper/v3.py#L54

2. That route is processed in here:
   https://github.com/anxdpanic/plugin.video.youtube/blob/36e037518bbb14a06a4928c9dd5b77baaa70c3d3/resources/lib/youtube_plugin/youtube/provider.py#L683-L698

So if you want to have "Play With Invidious" as the default action, while still supporting playing in the original way, then you'll have to change that line in item 1 to be something like:

            item_uri = context.create_uri(['playInvidious'], item_params)

And then add this new "playInvidious" route to your provider.py:

        @kodion.RegisterProviderPath('^/playInvidious/$')
        def on_play_invidious(self, context, re_match):
            params = context.get_params()

            if 'video_id' in params:
                xbmc.Player().play('plugin://plugin.video.invidious/?action=video&videoId=%s' % params['video_id'])
                return True

This is all untested btw, it usually takes a few tries to get it working right.
When changing the code of an add-on with lots of script packages like this one, in Kodi you need to long-press the add-on icon > Information > Disable, then Enable again so it reloads all its scripts, including your updates. Otherwise the internal packages are not reloaded.

Edit: fixed a typo. Thanks to christianhaitian for the tip.

[pitsi]

@anxdpanic Thank you for uploading the alpha versions in the testing repo!

[Dendraspis]

I have the same issues since a few weeks after updating to Kodi v19. Meanwhile I noticed that it helps to delete the data cache und function databases as well as the temp files via the plugin settings. It seemed, that the playback was smoother. Then I played a bit with the cache. Sadly the max size is 100MiB, which I had already set. So I changed it the min. value of 5MiB and again I flushed the databases and temp files like before. The result: Even less buffering interruptions.

Maybe coincidence or just imagination, but I would say, that the buffering issue still occurs, but noticeably less often. But nevertheless this buffering problem is soooo annoying...

Currently using Kodi v19.2 on Windows10 and v6.8.18.alpha2+matrix1.

[axvpast]

Looks like Google sometimes send to client broken URL with video stream. It is not problem related to your network and any Kodi buffers setup. TL;DR Use Odroid-C4, CoreElec 9.2.8 (last), Kodi 18.9, 4k TV (2160p@60, HDR), 1Gb WIRED Ethernet link with 100Mb Internet from ISP, which easy reach 10MiB/s speed. I think that it is my ISP or my DNS setup, or NTP create troubles and found something interesting about this issue. When I try to play video in folder /storage/.kodi/temp/plugin.video.youtube koid cretate mpd files. Inside MPD files you can find video stream URL using XPath: //Representation[@codecs='vp9']/BaseUrl/ So Kodi sometimes play this stream with dead buffering.... and you can see it using curl (checkUrl.sh):

LastYouTubeVideoMpd=$(ls -tr /storage/.kodi/temp/plugin.video.youtube/*.mpd | tail -n 1)

echo "Checking: ${LastYouTubeVideoMpd}"

YouTubeStreamUrlEncoded=$(cat "${LastYouTubeVideoMpd}" | grep "BaseURL" | head -n 1 | sed 's/.*<BaseURL>\([^<]*\).*/\1/' )

YouTubeStreamUrl=$( echo "${YouTubeStreamUrlEncoded}" | sed 's/\&amp;/\&/g' )

echo "Got YouTube stream URL:${YouTubeStreamUrl}"

curl -o /dev/null "${YouTubeStreamUrl}"

So can see curl statistics and it show that you download speed for this stream is low. But for working streams good. Also in url present interesting parameter: initcwndbps and if you got low value for this parameter you got troubles. I try to change it, but it's looks like signed and cannot be changed from our side.

So may be we just got dead/broken links from google and need ask it again till moment when we got good initcwndbps value? Also looks like exist value for this parameter above 1Mbit/s and all below 1Mbit/s transferred as 96kBps ? Some programmer from google miss one zero?

[probonopd]

Been testing "Play with Inviduous" (as described above) for a while now and did not encounter the buffering issues with it.

[arcaine2]

I've just updated to alpha2. So far every video plays at first try, no buffering during playback so far either.

[robastala]

Was using v6.8.17 with Kodi 19.1 on Ubuntu 20.04.

Today tried: plugin.video.youtube-6.8.18.alpha2+matrix.1.zip

so far its been night and day. No buffering issues.

Thanks!

[Rialtho-the-Magnificent]

not for me. playing on pi 3b+ and OSMC as OS. Going back to the previous installment. Now it is even worse! (that is: v6.8.18.alpha2+matrix1.)

[bzarky]

Installed alpha2 on my system and it appears to have fixed the issue. So far every video is playing without issue, though some videos will just stop playing if i press any key on the keyboard. Minor issue for smooth playback.

[Nigel1992]

Been testing "Play with Inviduous" (as described above) for a while now and did not encounter the buffering issues with it.

Thanks a lot for posting this workaround.

Working flawlessly on LibreELEC 9.2.8 (Kodi 18) on RPI 3B+

[pitsi]

I can try it on 18 and report back, provided that someone makes it a zip ready for installation because the code is too complex for me and I will probably mess something.

[RNavega]

@pitsi good to hear. If you can wait a couple of days, I'd like to try modding the latest version of this plugin to add some scraping code, so it can stream through these Invidious proxies without the need for that external add-on.
This Invidious service looks great, very promising.

[Rialtho-the-Magnificent]

gone back to previous installment but that makes no difference. Now no video plays oke, except one from a channel that is not using the ad revenue system I believe.

[pitsi]

@RNavega I can wait as long as you want. But... I have been using plugin.video.invidious addon by lekma as an "altenative" for 6+ months now. It has some issues but they are not related to the plugin itself but to the invidious api and more specificaly to its instances. So please, use an instance that works fairly well for everyone. Thank you in advance.

[probonopd]

Maybe a working instance could be picked automatically (randomized?) by consulting https://api.invidious.io/instances.json.

Better yet, study what they are doing (it's open source!) and implement the same strategy.

[axvpast]

Expecting invidious.io service crash after new Kodi YouTube plugin release :) Also I think brutal solution, with a lot of parallel open TCP connections win (Google limit speed to 70bBps? Just open 10-20 connections with small ranges in parallel). Return to NetVampire download strategy :)

Simple logic - open connection, try to get 0-10MiB range. Look into speed and calculate next range offset and size for next connection, if speed for sum firs connection and next is not good - calculate offset and size for next connection... So in case if speed at the begin is good - you use only one tcp connection. If speed is not good - a lot of connections which fills buffer in parallel. So you get buffering lag only in the begin of video.

[innerspacepilot]

This seems to be a problem with outdated youtube-dl youtube-dl 'https://www.youtube.com/watch?v=a3oQy6v3MrA' [youtube] a3oQy6v3MrA: Downloading webpage [download] Destination: (HOW) I fixed the Ugly Layers on my 3D Printer-a3oQy6v3MrA.f137.mp4 [download] 0.3% of 146.70MiB at 77.57KiB/s ETA 32:11^C ERROR: Interrupted by user Comparing to fresh youtube-dl fork yt-dlp -N1 'https://www.youtube.com/watch?v=a3oQy6v3MrA' [youtube] a3oQy6v3MrA: Downloading webpage [youtube] a3oQy6v3MrA: Downloading android player API JSON [info] a3oQy6v3MrA: Downloading 1 format(s): 248+251 [download] Resuming download at byte 4904480 [download] Destination: (HOW) I fixed the Ugly Layers on my 3D Printer [a3oQy6v3MrA].f248.webm [download] 9.0% of 74.17MiB at 1.23MiB/s ETA 00:54^C ERROR: Interrupted by user

[Nigel1992]

Does anyone know how to make "Play with Invidious" the default action when a video is clicked?

@probonopd

1. When a video item is created, it uses the /play/video_id=... route, created in here: https://github.com/anxdpanic/plugin.video.youtube/blob/36e037518bbb14a06a4928c9dd5b77baaa70c3d3/resources/lib/youtube_plugin/youtube/helper/v3.py#L54
2. That route is processed in here: https://github.com/anxdpanic/plugin.video.youtube/blob/36e037518bbb14a06a4928c9dd5b77baaa70c3d3/resources/lib/youtube_plugin/youtube/provider.py#L683-L698

So if you want to have "Play With Invidious" as the default action, while still supporting playing in the original way, then you'll have to change that line in item 1 to be something like:

            item_uri = context.create_uri(['playInvidious'], item_params)

And then add this new "playInvidious" route to your provider.py:

        @kodion.RegisterProviderPath('^/playInvidious/$')
        def on_play_invidious(self, context, re_match):
            params = context.get_params()

            if 'video_id' in params:
                xbmc.Player.play('plugin://plugin.video.invidious/?action=video&videoId=%s' % params['video_id'])
                return True

This is all untested btw, it usually takes a few tries to get it working right. When changing the code of an add-on with lots of script packages like this one, in Kodi you need to long-press the add-on icon > Information > Disable, then Enable again so it reloads all its scripts, including your updates. Otherwise the internal packages are not reloaded.

Gives a YouTube error after updating the provider file. I probably put it in the wrong section. Please help @RNavega :) My provider.py file: https://controlc.com/531e8380

Kodi 18.9 (Leia) LibreELEC 9.2.8 (Stable) RPi 3B+

Edit: never mind I'll wait for your modded version of this addon 👍

[robastala]

Was using v6.8.17 with Kodi 19.1 on Ubuntu 20.04.

Today tried: plugin.video.youtube-6.8.18.alpha2+matrix.1.zip

so far its been night and day. No buffering issues.

Thanks!

I spoke too soon. The buffering problem gradually came back.

[z0w13]

Feels like YouTube keeps messing with certain parameters to make playback more difficult, all my videos are buffering now too. Come on Susan

[tssajo]

Maybe a working instance could be picked automatically (randomized?) by consulting https://api.invidious.io/instances.json.

Better yet, study what they are doing (it's open source!) and implement the same strategy.

I already looked into it last night. Invidious seems to be written in Crystal programming language?? See: https://en.wikipedia.org/wiki/Crystal_(programming_language) Anyhow, they figured out a way to get working video stream links from Youtube without any need to decode any obfuscated data. This is achieved by using something called "Innertube API/Youtube internal API." Their solution is based on findings mentioned here: https://github.com/TeamNewPipe/NewPipeExtractor/issues/562 This technique is implemented in this Crystal ( .cr ) file: https://github.com/iv-org/invidious/blob/master/src/invidious/helpers/youtube_api.cr It doesn't look to complex to implement it in Python, IMO.

[arcaine2]

Feels like YouTube keeps messing with certain parameters to make playback more difficult, all my videos are buffering now too. Come on Susan

Yup, it's unplayable again. A single video can take 10, 20 or even more attempts to play correctly. What's intresting, the same video, from the same playlist works at first try on my Shield TV, also in Kodi with same version of the add-on.

[viper-666]

@probonopd I have get managed to get invidious installed on my libreelec installation and invidious works fine. But I can't get the counter menu entry for invidious. I edited the two files as you said to do but if I go on a video in the YouTube plugin and use the counter menu there isn't a "play with invidious" entry. Any ideas what's I make wrong...

EDIT: I found the issue, I used the wrong "def update_play_info" line, there are two and the second is right, now everything works!!!

[pitsi]

Maybe a working instance could be picked automatically (randomized?) by consulting https://api.invidious.io/instances.json.

Better yet, study what they are doing (it's open source!) and implement the same strategy.

The term "working" is a brave statement for the invidious api. Being a user of the addon for those 6+ months, I can assure you that even "100% health" for an instance means nothing. I have seen instances with 100% or very near to 100% health (e.g. 99 or 98) not returning any results for searches in general, not returning any results only for channels, returning results but not playing any of them, returning results and playing them with no sound and so on. Plus the wrong results in any search.

On top of that, instances come and go. A reliable instance I was using a few months ago does not even exist anymore. Luckily, the one I am now using (ytprivate.com) has been working for the last couple of months. I hope it still works though, I have not used it for a couple of weeks.

Anyway, I hope that the patch only "converts" the relevant url e.g. from https://www.youtube.com/watch?v=wpWFV41U5Wk to https://yewtu.be/watch?v=wpWFV41U5Wk and does the searches with youtube.

p.s. I did not choose yewtu.be randomly for the example. It works via a browser, but fails in the invidious addon. And it now has 100% health as seen here, in this user friendly table. https://redirect.invidious.io/

[notimp]

Still having the buffering issue with the alpha 2 release on the following video: https://www.youtube.com/watch?v=7MLdehTdNhk

[pitsi]

I also have videos that buffer when playing. It seems I have to use the addon more often than once every 3-4 days. Unlike last time that throttling was starting after 5 seconds, it now starts at 20-25 seconds in but once it is done buffering, it keeps playing until the end with no issue.

Kodi 18.9 on libreelec 9.2.6 x64, youtube 6.8.18-alpha2 and mpeg-dash enabled.

[Morgyn]

I believe youtube-dl is suffering with the same issue, they mention a fork that has it fixed: https://github.com/ytdl-org/youtube-dl/issues/29326

[S1lvr]

Can confirm same issue as everyone else, Kodi 18 on Raspbian

[urbanboy]

Same issue at Kodi Leia Libreelec RPI 3 B+.

[pitsi]

I think I made a small discovery. Despite having mpeg-dash enabled, I have set the addon to play videos at 720p. If i set the addon to always ask me for the quality, or if I right click on a video and select "play (ask for quality)", it will pop up a dialog box with the available options for it. The top option that has "mpd" as the "filetype" is the one that uses mpeg-dash.

Right now, that option no longer shows up on most videos, but it shows up as it used to for live streams. And guess which ones play as slideshows and which ones play with no issues... So, could this be the culprit? Maybe youtube's api blocked the addon's ability to use the mpeg-dash for the videos, so we are back to v6.8.17 behaviour :(

---edit @Morgyn You should see how yt-dlp works around that throttling issue. It tricks youtube that it sends the stream to the youtube android app! Check its changelog for 2021.07.07 here https://github.com/yt-dlp/yt-dlp/releases/tag/2021.07.07

[gatecrasher777]

Was using v6.8.17 with Kodi 19.1 on Ubuntu 20.04. Today tried: plugin.video.youtube-6.8.18.alpha2+matrix.1.zip so far its been night and day. No buffering issues. Thanks!

I spoke too soon. The buffering problem gradually came back.

It gradually comes back because emulated n-parameter transforms fail on newer/different releases of YT's base.js player code. The only fool-proof way to around it is to run the actual base.js n-transform functions... or like with yt-dlp fool Google into thinking you are on an Android device, which seems to work for now.

Perhaps moving towards using YT's innertube api like in ytcog with persistent sessions will give more reliable streams too. Rather than repeatedly hitting watch pages and getting different players - this is something that doesn't happen in a web user's browser. In the browser you will keep the same player base.js throughout the "session", and all subsequent info requests are serviced via the innertube api.

What Google is doing here is trying to ensure that people are using embedded code or viewing videos on their app or website, and penalizing those it thinks are circumventing their business interests.

[viper-666]

I think I made a small discovery. Despite having mpeg-dash enabled, I have set the addon to play videos at 720p. If i set the addon to always ask me for the quality, or if I right click on a video and select "play (ask for quality)", it will pop up a dialog box with the available options for it. The top option that has "mpd" as the "filetype" is the one that uses mpeg-dash.

Right now, that option no longer shows up on most videos, but it shows up as it used to for live streams. And guess which ones play as slideshows and which ones play with no issues... So, could this be the culprit? Maybe youtube's api blocked the addon's ability to use the mpeg-dash for the videos, so we are back to v6.8.17 behaviour :(

---edit @Morgyn You should see how yt-dlp works around that throttling issue. It tricks youtube that it sends the stream to the youtube android app! Check its changelog for 2021.07.07 here https://github.com/yt-dlp/yt-dlp/releases/tag/2021.07.07

I haven't MPEG-Dash on and always choose the video quality but have the stuttering issue.

[gatecrasher777]

Just to be clear. Streams will buffer randomly on any hardware, any code base, any language, any stream type, any platform/os (except android) where the n-parameter challenge fails. Because that is what Google have designed it to do.

[develroo]

Yeah well seem youtube-dl itself is being throttled so anything else based on it is as well. I can take the same video and download it with yt-dlp and it is at full speed. I think some small refactoring is in order to add either other external downloaders, or include the code for it.

It is quite frustrating sighs