It’s wrapping a somewhat opinionated and mildly bizarre yt-dlp invocation, for each line of a file doing a mkdir/cd and then invoking yt-dlp.
—⁂—
From the “Features” section of the README:
> • Organized Structure: Creates separate directories for each channel.
… depending on you mentioning that name in your playlists.txt file, so that if you were writing a script you’d just be doing a mkdir/cd yourself, trivial.
> • Smart Sync: Skips files that have already been downloaded (--no-overwrites).
That’s not really what --no-overwrites does. The default of --no-force-overwrites is probably actually what you want: “do not overwrite the video, but overwrite related files”. You probably do want metadata files to be updated on subsequent runs.
> • Clean Naming: Saves files as Playlist Title/Video Title.mp4 (no numeric prefixes).
This is an Opinion.
> • Batch Processing: Reads multiple playlists from a playlists.txt file.
Meh, you’re invoking a script, putting the stuff in the script would be at least as easy.
—⁂—
From the script itself, going through the arguments passed to yt-dlp:
--cookies "$COOKIES_FILE"
My impression is that this is discouraged unless necessary. And if you need it, --cookies-from-browser will be more convenient.
-f "bv*+ba/b"
That’s equivalent to the default.
--merge-output-format mp4
This is an Opinion.
--no-overwrites
I’m not convinced this is desirable. Videos already won’t be overwritten by default, this just stops metadata from being updated on subsequent runs, though I’m not sure what things might be updated.
-o "%(playlist_title)s/%(title)s.%(ext)s"
This is an Opinion.
—⁂—
Instead of having a playlists.txt file containing `Channel Name|https://www.youtube.com/playlist?list=x` and having a separate 73-line file download_playlists.sh, you might as well have just one download_playlists.sh file containing:
By dint of its simplicity, easier to work with and tweak to your own requirements (such as dropping `--merge-output-format mp4` as I did here). Also more obvious how to invoke it just once. (Aside: use pushd/popd instead of `cd "$channel_name"` and `cd ..`, because then $channel_name containing a slash won’t bork it.)
The repo should mention a warning about usage. Be aware that downloading large playlists with lots of videos from Youtube can get your ip address throttled/banned. The ban could last a week or a month.
It's also not a good idea to use "--cookies" unless you absolutely have to. Just leave out the cookies option and try to dl anonymously. Only when Youtube forces your ip address to "sign in" is it necessary to pass in cookies.
Exactly. There’s been account ban reports from it too. Id be very careful if it’s your normal google account that’s tied to YouTube. Always use a burner account when using the cookies param to be safe.
Unrelated, but I want to move from a Google account youtube feed to something a bit more client-side where I have the control but my main problem is the YouTube recommendation algorithm.
I feel like after a decade and a half google knows pretty well what I like and what I'm interested in. I built that homepage brick by brick.
Whenever I tried other youtube clients or ungoogled alternatives the recommendations were all really generic and not that good. Of course I won't find something that matches the real deal, but at least I want to:
1. Steer away from viral content, aka Mr Beast videos or whatever.
2. Have discoverability of youtube videos I would be interested in but that I'm not subscribed to yet.
To this day I still find new channels or videos I'm really interested in on my recommended feed.
Agree. Now it's easier to ask you favorite command line AI (e.g. Gemini CLI) something like "download this list of playlists with yt-dlp" rather than learn someone else's code or even check the manual.
The script linked was just vibe coded. Ai isn’t that great with the ytdl params, yet. It’s obvious because if an LLM really knew how to use ytdl it would have used the input file option instead of looping through a file and invoking for each one.
When downloading multiple playlists, it is usually better to organize them into separate folders so the files don't all end up in one giant mess. You can use an output template to automatically create folders based on the playlist title:
yt-dlp -a playlists.txt -o "%(playlist_title)s/%(playlist_index)s - %(title)s.%(ext)s"
To get YouTube videos offline on your phone/tablet for flights:
1. Create a playlist called “download” and add the videos you want.
2. Use yt-dlp (playlist URL) or this tool to pull that playlist to a folder.
3. Run the downloader on your Plex box on a schedule (cron/launchd).
4. Add that folder to Plex as a library.
5. Enable downloads for that library in Plex, then sync to your device.
I don't understand. yt-dlp already downloads a whole playlist if you pass it a playlist URL. What does this tool add?
It says "by channel name" but then it seems like you still have to pass in each playlist URL separately.
This is just a "wrapper" for something yt-dlp already does?
It’s wrapping a somewhat opinionated and mildly bizarre yt-dlp invocation, for each line of a file doing a mkdir/cd and then invoking yt-dlp.
—⁂—
From the “Features” section of the README:
> • Organized Structure: Creates separate directories for each channel.
… depending on you mentioning that name in your playlists.txt file, so that if you were writing a script you’d just be doing a mkdir/cd yourself, trivial.
> • Smart Sync: Skips files that have already been downloaded (--no-overwrites).
That’s not really what --no-overwrites does. The default of --no-force-overwrites is probably actually what you want: “do not overwrite the video, but overwrite related files”. You probably do want metadata files to be updated on subsequent runs.
> • Clean Naming: Saves files as Playlist Title/Video Title.mp4 (no numeric prefixes).
This is an Opinion.
> • Batch Processing: Reads multiple playlists from a playlists.txt file.
Meh, you’re invoking a script, putting the stuff in the script would be at least as easy.
—⁂—
From the script itself, going through the arguments passed to yt-dlp:
My impression is that this is discouraged unless necessary. And if you need it, --cookies-from-browser will be more convenient. That’s equivalent to the default. This is an Opinion. I’m not convinced this is desirable. Videos already won’t be overwritten by default, this just stops metadata from being updated on subsequent runs, though I’m not sure what things might be updated. This is an Opinion.—⁂—
Instead of having a playlists.txt file containing `Channel Name|https://www.youtube.com/playlist?list=x` and having a separate 73-line file download_playlists.sh, you might as well have just one download_playlists.sh file containing:
By dint of its simplicity, easier to work with and tweak to your own requirements (such as dropping `--merge-output-format mp4` as I did here). Also more obvious how to invoke it just once. (Aside: use pushd/popd instead of `cd "$channel_name"` and `cd ..`, because then $channel_name containing a slash won’t bork it.)The repo should mention a warning about usage. Be aware that downloading large playlists with lots of videos from Youtube can get your ip address throttled/banned. The ban could last a week or a month.
It's also not a good idea to use "--cookies" unless you absolutely have to. Just leave out the cookies option and try to dl anonymously. Only when Youtube forces your ip address to "sign in" is it necessary to pass in cookies.
Exactly. There’s been account ban reports from it too. Id be very careful if it’s your normal google account that’s tied to YouTube. Always use a burner account when using the cookies param to be safe.
I've been glancing at ytdl-sub, which does the same thing but with interesting options to rate limit.
https://ytdl-sub.readthedocs.io
Unrelated, but I want to move from a Google account youtube feed to something a bit more client-side where I have the control but my main problem is the YouTube recommendation algorithm.
I feel like after a decade and a half google knows pretty well what I like and what I'm interested in. I built that homepage brick by brick.
Whenever I tried other youtube clients or ungoogled alternatives the recommendations were all really generic and not that good. Of course I won't find something that matches the real deal, but at least I want to:
1. Steer away from viral content, aka Mr Beast videos or whatever. 2. Have discoverability of youtube videos I would be interested in but that I'm not subscribed to yet.
To this day I still find new channels or videos I'm really interested in on my recommended feed.
I, on the other hand, turned off YouTube recomendations with UnDistracted. Maybe I'm missing out; who knows.
You can get RSS feeds of channels still. I use that in my feed reader
Revanced you can still have the same algo. Also smarttubr
yt-dlp is second only to ffmpeg in being a pillar of functionality that gets frequently wrapped in convenience scripts
In this case I'm not sure why a convenience wrapper is even needed, yt-dlp already works with playlists just fine
Agree. Now it's easier to ask you favorite command line AI (e.g. Gemini CLI) something like "download this list of playlists with yt-dlp" rather than learn someone else's code or even check the manual.
The script linked was just vibe coded. Ai isn’t that great with the ytdl params, yet. It’s obvious because if an LLM really knew how to use ytdl it would have used the input file option instead of looping through a file and invoking for each one.
> Ai isn’t that great with the ytdl params
Gemini nails it:
When downloading multiple playlists, it is usually better to organize them into separate folders so the files don't all end up in one giant mess. You can use an output template to automatically create folders based on the playlist title:
yt-dlp -a playlists.txt -o "%(playlist_title)s/%(playlist_index)s - %(title)s.%(ext)s"
Interesting, must be a new fix. A couple months ago I tried to have it create a command and it hallucinated params.
>I'm not sure why a convenience wrapper is even needed,
Author wanted yt-dlp to be fed with a custom text file: "playlists.txt"
The script loops through that text file, parses it, and then launches yt-dlp for each valid line with a channel name.
Which is essentially just this:
I'm not sure if that warrants a HN postRight? Just add this to .bashrc:
alias yt-pl='yt-dlp -o "%(channel)s/%(playlist_title)s/%(title)s.%(ext)s" -a playlists.txt'
So -o "%(channel)s - %(title)s.%(ext)s", --batch-file and optionally --download-archive?
https://github.com/yt-dlp/yt-dlp#:~:text=channel%20%28string...
https://github.com/yt-dlp/yt-dlp#:~:text=%2Da%2C%20%2D%2Dbat...
https://github.com/yt-dlp/yt-dlp#:~:text=%2D%2Ddownload%2Dar...
Not to mention that the script is clearly LLM-generated
Or... just pay them that thing called money, and use the buttons in the YouTube app.