Very slow downloads

[mh4ck]

Hello, since a few days the lib is downloading youtube videos with around 50kbit/s. Anyone else recognized this issue?

I've read that YouTube changed smth. but the n param should fix this. This is already commited in latest version (which i am using) but it still downloads very slow.

Is there a workaround or fix for this?

[augusto]

I kind of have the same issue. I have a little web app that gets the download links. If I download the file with the browser directly from googlevideo.com, the download is super fast. If I proxy the request through the web app (the web app fetches the file and streams it back), the transfer is slowish (~250kbps). I tested this with the app runs on my computer, so there's no really extra latency.

It could be a matter of setting the right headers so google thinks the request does come from a browser rather than a tool, as I get the same slowish transfer if I use the url with curl/wget.

[redbrain]

Previous issues with throttling were fixed as of v4.9.2. Can you replicate this behavior on the most recent version of ytdl-core?

[mh4ck]

@augusto Yes iam using the latest version "version": "4.10.1", but even with this fix it's slow

Setup:

• Sending chrome user agent
• Tried over my Homepc, my proxies and bought fresh proxies from another hoster
• Sending cookie

everywhere the same - i even tried youtube-dl to test if this is just a ytdl-core problem but it's the same.

Normaly i am using the audioonly filter, i also tried audioandvideo and it's the same.

I also made a speedtest of the server to be sure that this is not just a network issue at the hoster side but there is no problem the server got fullspeed and regarding that it's also not working from my home computer it's not a bandwidth problem.

I mean the download is working but super slow with around 50kbit/s like i said.

---

For a test i developed an electron youtube video downloader that's going to the watchpage wait until the video is loading and fetching the webm/weba url and saving it. That's a lot faster, but also not super fast. So it can't be an issue with my IP's i guess.

[TimeForANinja]

can you check if there's more bugs with the n-transform?

[Michal-Szczepaniak]

Yep, the previous fix was working until recently, reported by multiple people

[kiroslav]

This issue is still present

[gatecrasher777]

I notice this issue was raised 2 days after PR #1055. The fix in #1055 was also applied in ytcog. Working with it every day since I have not picked up any consistent slowdowns. If anyone can replicate the issue it would be helpful if the base.js address info.html5player can be recorded along with the slow video id.

[miniwa]

This is a problem for me as well and not just with downloads. Calls to ytdl.getInfo consistently take ~500ms to complete.

[MistakingManx]

I'm also having this issue, but now I'm getting 429 errors out of literally no where.

I've made no requests in the past 3 days and then suddenly my VPS got a 429 error on my first request. The IP is not shared.

[gatecrasher777]

Just to note there are no 429s using innertube requests, whether logged-in or not. And the info requests to https://www.youtube.com/youtubei/v1/player are instantaneous. This project could benefit a great deal from moving to the innertube api.

[TimeForANinja]

Just to note there are no 429s using innertube requests, whether logged-in or not. And the info requests to https://www.youtube.com/youtubei/v1/player are instantaneous. This project could benefit a great deal from moving to the innertube api.

by now i'm personally down to switch but i'm not sure where to find the time to rewrite half the library 😅

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.