Use yt-dlp instead of youtube-dl

[jr1221]

Feature Request

Description

Since youtube-dl is without a maintainer and updates, the seemingly random throttling youtube employs #210 is no longer fixed in that package. Switching to yt-dlp fixes these issues, and maintains near 100% compatibility with youtube-dl python bindings and command line options.

[deepjyoti30]

@jr1221 I thought the throttle issue was fixed with the last release of youtube-dl. Not sure if it started happening again?

I guess moving to youtube-dlp is the logical step at this point now.

[jr1221]

@deepjyoti30 It seems so. Nevertheless, nobody will be making releases to fix an issue if it arises.

[deepjyoti30]

@jr1221 I have added init support to move to yt-dlp. You can test the unstable branch and let me know here if you face any issues.

Reference commit: 0eb0cb8

[jr1221]

@deepjyoti30 Yesterday youtube-dl got a new maintainer, so eventually they will take the backport to fix throttling from yt-dlp. However, I believe yt-dlp will remain the standard.

I tested out the new change, I bisected an issue to this commit in which I recieved:

ERROR: Download failed for `https://youtube.com/watch?v=iqu132vTl5Y` with error: 'Logger' object has no attribute 'level_map' . Pass `--ignore-errors` to ignore this.

With ignore errors:

==> --ignore-errors passed. Skipping this song! 

[pukkandan]

Why not look for either package. Something as simple as this could work:

try:
    import yt_dlp as youtube_dl
except ImportError:
    import youtube_dl

Even better if a commandline argument can be given for the user can choose. Since yt-dlp API is mostly compatible with youtube-dl and the project is not making use of any yt-dlp specific features, this shouldn't add any additional maintenance cost.

[deepjyoti30]

@jr1221 The issue you pointed out is not from ytmdl but from simber instead. Consider installing the latest unstable commit from simber locally and this issue should go away.

[deepjyoti30]

@pukkandan That is a nice idea actually, however, at the top of my mind, I had to make two changes while adding support for yt-dlp, one being a significant one. As it turns out when playlists are extracted, in case of ytdlp the url field contains the whole URL and in youtube-dl, that field just contained the href.

I am not saying that these are major changes and these can be handled if the support for both libraries are to be kept but my concern is, in the long run, if youtube-dl and yt-dlp's source code bisect even more, it will become an issue to keep support for both.

At this point the question is what advantage is there if we let the user decide between youtube-dl and yt-dlp? At the end of the day ytmdl is supposed to be able to get them a song ready (without raising any issues) and the choosing the underlying library should not be there concern.

Though, I like the idea of giving them the flexibility to have more than one option, let me see how viable that would be and if it will be worth the trouble that we might face in the long run.

[pukkandan]

As it turns out when playlists are extracted, in case of ytdlp the url field contains the whole URL and in youtube-dl, that field just contained the href.

See my comment on 0eb0cb8#r65250114

[deepjyoti30]

@pukkandan Thanks, looked into that!

[deepjyoti30]

Seems like youtube-dl still doesn't have any new releases so I will skip keeping youtube-dl support for now. Perhaps in the future, both yt-dlp and youtube-dl can be supported.