I switched to yt-dlp a few months ago, under the impression that youtube-dl was no longer maintained? At least for youtube purposes, at least for the one crucial issue that forced me to switch. I forgot what the issue was, but it had several PRs sitting there for months and nobody was gonna merge it.

What wasn't maintained for you?

In that I mean what feature was missing or broken for you?

As software gets more stable, updates should be less frequent.

I'm not a fan of feature creep in the name of progress.

I am a fan of options though, so if there was an necessity for a fork I support it.

> As software gets more stable, updates should be less frequent.

But a project like youtube-dl needs frequent updates, because otherwise it'll stop working after an update from Google.

I'm not the parent, but the "a few months ago" timeline makes me think they switched to yt-dlp in December 2021 when youtube-dl did not work for a few days after it broke due to a change from Google. There were PRs quickly made to fix the issue (some of which actually predated the breakage if I remember correctly) but no one was around to merge them for a few days. This is also the time the project's maintainer officially became inactive[1].

1: https://github.com/ytdl-org/youtube-dl/commit/21b759057502c6...

> But a project like youtube-dl needs frequent updates, because otherwise it'll stop working after an update from Google.

Right, but as a frequent user of youtube-dl it has been working for me, I was curious what wasn't working.

Your explanation of the few day PR merge delay explains the fork though, thank you.

>What wasn't maintained for you?

>In that I mean what feature was missing or broken for you?

youtube-dl got throttled, it took ages to download videos from Youtube.

Interesting. How did they identify youtube-dl to throttle it, and what was the workaround?

YouTube throttles the download speed of videos to the real-time playback speed. It also provides (if I recall correctly) a random token and a JS blob; if the client executes the JS and passes in the token, it gets another random token as output that if passed along with a request will unthrottle the downloads speed. As a result, full-speed downloads are only available to clients that can safely execute untrusted JS, which is mostly web-browsers and not command-line tools.

I believe the way yt-dlp works is that somebody manually ported the JS blob code to Python, which gets things working but leaves a lot of scope for arms-race escalation in future.

With the current toolsets like Puppeteer or Playwright, doesn't seem like a tough matter to solve?

They didn’t. They added a challenge–response step to downloading the video, and throttled any request for the video that doesn’t include the correct response to the challenge. The webpage has some JS that computes the correct response, so you don’t get throttled if you view a video there. You can find the details in the bug tracker if you want.

As of a few weeks ago my download speeds with youtube-dl were about 150Kb/s and 50Mb/s with yt-dlp. The missing feature from youtube-dl is that it could not download videos in a reasonable amount of time — a fairly necessary feature.

Porn mostly.