A cross-platform GUI for YouTube-dl | Hacker News Reader

A cross-platform GUI for YouTube-dl

github.com

429 pointsducktective151 comments

I built my own personal version where it runs in the background and automatically downloads stuff I like (I highly curate my likes) or send to select playlists. Too often I go through my favorites and see deleted videos so I just cooked up something one weekend. I have an entire hard drive dedicated as an offline archive where I can playback at anytime, search the library and it even alerts me if any video or audio I saved was deleted (I have quite some rare pulled videos). It will also grab the subtitles/transcript if available, description and top 100 comments (if a tutorial etc).

https://i.imgur.com/yxlRTI8.png

Do you really need Electron for this? I would implement what you describe in a headless Python (which is native to YouTube-dl and where YouTube-dl itself is available as a library) script.

I just use a shell script.

For a frontend dev, it makes sense to use Electron for personal projects of this variety. You don’t need to learn another language, or even another set of tools, you just build the whole thing in-browser and get a shareable UI to boot.

Personally, I’m partial to the command line and to a lesser extent, TUIs, but I certainly understand building with whatever is most convenient and/or fun to the dev…especially on a personal project!

Full stack dev here, I work with c++ and other langs often and do work with web tech for clients, dcc scripts and plugins etc. This took me a few hours with electron because it's just js and I don't want a crummy cli, tui or generic gui look, I want something with batteries included that's easy to style, quick to add new functionality if needed (npm) and looks GOOD besides this isn't for anyone but me.

Do you really need Python for this? I would implement what you describe in SwiftUI (which is native to my OS) code.

I don’t understand what you care for other people’s personal projects. Not everyone knows your favorite language.

Python is not my favorite language. It's a basic language youtube-dl itself is implemented in. I would say bash but bash is hard. Even if I were an excavator driver I would still use an ordinary shovel for a personal project of planting flowers in my garden.

You're constraining yourself to a language for no good reason. With your logic, we'd all be writing C. Communicating with ytdl from any other language via a library or even a process call is rather trivial so just it being written in python is already a non reason.

I chose js a la electron because I needed a nice gui I could style and add user friendly interactions with minimal work to amongst several other reasons, the aim was to have a nice way to browse my archive and track what goes in, not create new work. If I just wanted videos I could easily have done this with a script, a browser extension or any of the zillion ytdl variants available. By just scaffolding a new project I had already met a lot of requirements, easily embeddable iframes, no external video player, instant search (fusejs) and the list goes on. This is also my first electron project and first time using it so go figure, heh.

Also funnily enough the first quick draft of this was in python using qt and lived in my taskbar tray which served a simple html page and ran in the background but it wasn't fun to use and required a lot more work rather than just mindlessly pulling down packages to use in a fun side project.

I was playing around with something similar a while back.

https://github.com/bluedaze/ytADL

Neat! Seeing this I'm considering making a similar project that takes a search and drops the preview pictures. No post-video-watching suggest + no 1 minute video shorts + no clickbaity preview pictures + setting a watch timer or something like that might get me back on youtube.

You can try this addon (Unhook: Remove YouTube Recommended Videos Comments) as it does just that and more, my web yt is clean, I don't even have a feed thanks to this.

Chrome - https://chrome.google.com/webstore/detail/unhook-remove-yout...

FF - https://addons.mozilla.org/en-US/firefox/addon/youtube-recom...

This is exactly what I have been looking for, any chance you could make this public?

Unfortunately no immediate plans to do so. It was a quick weekend project to scratch an itch.

It's comments like this that make me realize that not everyone has an utilitarian mindset. I'd be happy to share my weekend project if someone expressed interest, even if it wasn't perfect. Just don't expect me to support it.

Support is one and you can't blindly assume that it's in a shareable format from a quick braindump sprint. Lots of hardcoded personal stuff, wonky incomplete features, mixed absolute and relative paths etc. It was NEVER intended to be shared and would require time to cleanup to even distribute a binary. It also works based on how I use youtube, it's not a general purpose tool so it's super opinionated. I simply shared it here because it seemed relevant to the topic. :)

Yeah, I think with the "share everything" mentality and everyone building everything in reusable jS snippets (thus, the huge repositories of code and duplicated projects); the general share of people forget that some people still code...for themself. And that those projects don't necessarily have a simple "settings.toml" to edit for paths or settings; nor the tons of effort that goes into making such a project configurable in the first place.

And there's nothing wrong with that. Like the dozens of PoC codebases I have lying around my PC that no one will (or needs to) ever see.

You don't need code for this... if you pass youtube-dl a playlist URL instead of a video URL, it will download all (public) videos from the playlist. Write a cron job for it and you're done.

You might enjoy youtube-local: https://github.com/user234683/youtube-local

Could you share the code for this? It looks great!

I built my own to browse large video collections: Video Hub App https://videohubapp.com/

MIT open source: https://github.com/whyboris/Video-Hub-App

No plans to share yet as it's a mess tbh and it's nothing special, your version seems way more advanced. Regarding the look, I just wanted a bit more control over my UI which I styled with tailwind, this is also an older screenshot, looks a lot better now.

An idea that anyone is free to take: JSON-definable UI for command-line apps. Define checkboxes for flags, inputs for arguments, buttons for commands and file pickers / droppable wells for file input. Allow some customization of layout of these elements. Have in-app "store" to download these JSON definitions, maybe even suggest them based on `which` output. Electron app, obviously.

XML based UIs already exist with GtkBuilder and QtQuick(?). Although, your idea is more complex than that.

HTML is a pretty good XML-like UI builder.

That sounds like Gooey: https://github.com/chriskiehl/Gooey, which creates GUIs for Python cli apps.

Autogenerated based on the args, but configurable and the widgets and menus can be defined in JSON.

Gooey is a great northern star to follow, but this hypothetical app should work with any command-line app.

Idea would be to define UI structure that outputs (and executes) essentially a string (command) to run.

Not JSON, but related: Kaptain.

https://github.com/mviereck/kaptain

This is cool! Syntax might scare off many developers, I think one of the goals should be approachability, it should be super easy to transform your favorite command-line app into a GUI.

I've been asking HN for this some time ago: https://news.ycombinator.com/item?id=27820141

Also see: https://news.ycombinator.com/item?id=28461133

It seems to me that a lot of these projects aim to deliver really "good" apps: native UI, table output, etc… Results are great, but the UI building complexity also becomes quite high.

I think that's the wrong goal. The goal should be really simple definitions and ok quality apps. Simple JSON (or XML, don't care).

    { control: checkbox, flag: c, label: "Compile" }

So like a modern day VB3 but built on Electron. Would be nice to have!

preferably not electron :)

I get the hate for Electron, but to me, despite the issues, it's not going away.

I think a better approach is to figure out how to make Electron more performant in the various OSes.

I haven't gotten into the internals of Electron, so I'm not the one to reflect on the approach, but seeing some of the improvements that MSFT made with Edge over Chrome in memory usage gives me hope that this is achievable, even if it doesn't happen immediately.

Back in the 1990's we faced a similar thing, where web "apps" were ugly and slow, and not as powerful as the desktop apps that many corporations had developed in C++ or VB or Delphi. Today of course, the situation is much different, and we use web apps all the time. I really truly believe that Electron (or perhaps a successor - like how VS Code superseded Atom) will not go away, and in the future we will be much happier with it.

> back in the 1990's we faced a similar thing, where web "apps" were ugly and slow

And when's the last time you loaded an app with the Java VM on the desktop, unless it was Eclipse and you were about to use it to write more Java?

Minecraft. q.e.d.

That's true. I forgot Minecraft. I now have two examples (Eclipse, Minecraft). Although Minecraft moved away from Java to native clients for consoles, mobile and even a Windows native version.

Why JSON? Just use a simplified subset of HTML and ignore styling+scripts for commandline. And for GUI/Web you can still offer the full HTML+CSS+Scripting-experience.

Can be XML as well, but I think HTML is too complex. The goal, for me, is simplicity.

    <section name="Options"><checkbox flag="c" label="Compile" /></section>

It shouldn't be a hassle at all to convert a man page to a UI that speeds up actions and avoids common errors.

Anyway, this idea is free, so feel free to take it and do whatever, even full HTML (:

I don't see how yet another ui-definition-format will help to make things simpler. And what UI does a manpage need? Manpages are documents, they have no real ui.

I think op meant covering a man page for a command into a gui for the command, not into a gui for the man page.

> HTML is too complex

The suggestion was a simplified subset of HTML.

Sounds a bit like Sciter, then.

This would require some sort of open-api type spec but for CLIs. I like this idea. Good luck to anyone taking it up.

Everything doesn't have to be JSON ;)

Agreed. The best format might be one specially defined for the job.

I built a GUI-builder ages ago (in Python, compiling to Python which calls Tkinter to build the GUI). Here's a sample of what the UI-definition language looked like: https://github.com/cabalamat/parrot/blob/master/simple2.par

Looks fine and dandy but could also be represented in JSON with not much effort and then you'd be using an interchange format understood by many tools instead of a bespoke language.

I'm definitely biased being a web dev but JSON is just so widely used and supported... seems ideal for small bits of config like this.

> Looks fine and dandy but could also be represented in JSON with not much effort

Yes it could. But writing the UI descriptions would be harder in JSON than in my bespoke language.

My goal in writing the tool was to maker UI descriptions as easy to write as possible. If I hadn't cared about that I wouldn't simply continued to hard-code them in Tkinter.

> I'm definitely biased being a web dev but JSON is just so widely used and supported

JSON didn't exist when I originally wrote this. If i was doing it today, it's entirely possible I would use JSON as a data interchange format.

> But writing the UI descriptions would be harder in JSON than in my bespoke language.

For example, this:

    menu "File" {
        menuItem @New "New"
        menuItem @Open "Open..."
        menuItem @Save "Save"
        menuItem @SaveAs "Save as..."
        menuItem @Exit "Exit"
    }

Might become something like this:

    {'widget': 'menu', 'text': 'File', 'contents': [
            {'widget': 'menuItem', 'id': 'New', 'text': 'New'},
            {'widget': 'menuItem', 'id': 'Open', 'text': 'Open...'},
            {'widget': 'menuItem', 'id': 'Save', 'text': 'Save'},
            {'widget': 'menuItem', 'id': 'SaveAs', 'text': 'Save as...'},
            {'widget': 'menuItem', 'id': 'Exit', 'text': 'Exit'}
        ]
    }

Which would turn writing a UI from something that's a pleasure to something that's a chore. People who would deliberately write software that's a chore for others to use ought not IMO be writing software that will be used by other people.

IMO, using JSON to specify a GUI would be a terrible idea. Its purpose is to serialize data for transport between disparate systems. JSON is verbose and writing anything decently complicated with it sounds like torture.

What you want for something like a GUI specification is a DSL designed for the task (e.g. QML), or a suitable general purpose language like HCL or YAML.

> JSON is verbose and writing anything decently complicated with it sounds like torture.

Except in comparison with XML :-)

You have to define the behavour of your UI elements as well as their placement, at which point you're writing a program.

The best language to write a program in is a Turing-complete programming language specially designed for that task, not some cobbled together UI-definition language with ad hoc add-ons to processing.

Everyone has different requirements. For many things, I'd take a quick JSON file configuration over having to write everything from scratch again and reinventing the wheel.

Like it or not, the whole low code movement is about this.

> I'd take a quick JSON file configuration

Let's say your GUI has several input boxes. You want to validate those boxes. You need something Turing-complete to do this, because if it isn't Turing complete and the tool is used by lots of people, someone's GUI will require it.

> the whole low code movement is about this

That's OK provided you accept that it limits what can be done.

The best clothes are hand-tailored specifically to fit your body.

And yet, most people wear mass-produced clothes.

Well yes but to continue the metaphor almost nobody wears barrels

Mass produced clothes are significantly cheaper than barrels. Several orders of magnitude.

You have now been subscribed to Barrel Facts. Whiskey barrels are really expensive and the method to make certain types is passed down through generations. The tightness of the barrel and the type of wood are both considered as the wood will expand a bit from absorption of its contents. An amount of whiskey loss is accepted from evaporation of the contents through the porous wood of the barrel. A considerable expertise is necessary to create quality barrels. [1][2][3]

Each type of wood is used for aging different spirits. Oak is most common in whiskey and wine making. Sometimes the barrels are even smoked near a fire to impart a unique flavor into the alcohol that will be held in the barrel. A used barrel is very desirable and can go for higher prices on the open market than even a quality new barrel. This price parity is due to the unique flavor that can be impacted by using a used wine barrel for whiskey, used whiskey barrel for wine, or some other unique alternation of barrel contents.

Barrels that are hundreds of years old, and thick with aged bacteria are used for making traditional Japanese soy sauce. These special family heirloom barrels will be used for many generations before they are eventually retired. [4]

[1] https://youtu.be/ccoHCSKMf-E

[2] https://youtu.be/GE7QA1chUzw

[3] https://youtu.be/kaXvFw8ve_I

[4] https://youtu.be/1mc2g8Ue-hI

The way I look at this, the UI would be only to speed things up / simplify things a little bit. It wouldn't try to do full error validation before execution. It's the job of a command-line app to fail with an error if wrong combination of flags or inputs was provided, and the UI might display that error in a pretty generic way.

HTML is the only successful really cross-platform GUI system (text console, text-to-speak, Win, Mac, Lin, Android, iOS, Symbian, embedded, etc.) created so far.

Indeed. Whenever someone suggests some kind of "UI" language, I just point to HTML/CSS. It's by no means perfect, but it's good enough and as ubiquitous as anything ever.

i was surprised how close this gets https://sanana.kiev.ua/index.php/yad

For native Mac apps, there is Platypus that does something similar: https://sveinbjorn.org/platypus

For those who have lots of videos on your computer (cross-platform), I built Video Hub App to browse, search, and preview videos (works with external and network drives). Hope you like!

https://videohubapp.com/en/

MIT open source: https://github.com/whyboris/Video-Hub-App

I’ve been using this[0] GUI for years which is cross platform (Python not electron) and works amazingly. Let’s you do custom download formats, and accepts any input normal YouTube-dl accepts (videos, playlists, channels, etc). I use it almost daily.

[0] https://mrs0m30n3.github.io/youtube-dl-gui/

Do you experience any issues with it? Seeing as it hasn't been developed further since 2018, while youtube-dl is still being worked on (including new features).

I certainly did. Issues like crashing out of nowhere, silently failing downloads, etc. So I switched to the CLI option even though I'd have strongly preferred to be able to use the GUI. I was excited by the title of the HN post and then disheartened to see a program of the same name (as I assumed it was this buggy one), glad to see it's a different program.

I’ve honestly never had a single issue with it and wasn’t exaggerating when I said I use it nearly every day. I save any/every video I find useful to my NAS because I don’t trust Google not to delete the persons account for some arbitrary reason.

The only “gotcha” is sometimes downloads fail and if you don’t know to check the logs (in the top menu) then that can get confusing for new users, but usually it’s something simple like you need to update the YouTube-dl core (also just done via the menu) or you chose a download format/resolution not supported for that video.

youtube-dl doesn't seem to be getting much in the way of updates since the event but yt-dl fork has continued to progress and has fixed a lot of the weird problems that had crept up as youtube changes things. It also has a port of the GUI that goes along with it - https://oleksis.github.io/youtube-dl-gui/

Many in here don't understand why you need this if it's a CLI app which obviously means you could probably monetise this and earn a living from it.

If it’s monetized, I doubt many users would get it. There’s already many web based YouTube downloaders (that are free); Just Google “download youtube”. Sure, youtube-dl supports a hell of a lot more than just YouTube, but not everyone knows that.

I assumed that most of the web based ones were using youtube-dl behind the scenes.

How did you reach that conclusion from your premise?

I read it as half-sarcastic.

A sincere half is that technical users can't quite understand what less-technical users would appreciate.

The tongue in cheek half of "why not just..." will always smell a bit like the infamous comment discussing how DropBox doesn't provide value, since anyone could set the same kindof thing up themselves.

I think there’s a massive legal risk from monetizing something that exists to download mostly copyrighted content.

If you're downloading so you can watch it and not for rebroadcast there's literally no difference functionally or legally between clicking a link and opening it in a browser and using youtube-dl . The upside is when someone's account gets terminated for whatever reason you can still watch the content.

In case you're wondering: yes, it uses Electron. Because you definitely need yet another browser just to watch youtube videos.

Why not use FreeTube (https://github.com/FreeTubeApp/FreeTube) then if it is based on Electron anyway? Freetube also has support for watching videos directly alongwith downloading and can also route the video through Invidious servers if you prefer not giving your IP address to Youtube.

It's a wholly different use case. FreeTube is meant as a full replacement for the YouTube site. This app is a frontend for youtube-dl and concentrates on quick downloads noly.

To download them, not to watch. You still are going to watch in a native player like VLC, MPV, MPC or whatever, and also have the video backed up (which is important as YouTube videos get deleted often).

If only the Web had a file API.

https://developer.mozilla.org/en-US/docs/Web/API/FileSystem

I just don't get these kind of comments. This person's javascript knowledge enabled him to develop this multi-platform app, it looks and feels great and does its job. Yes, it uses a lot of memory (140mb by just opening it) but how long does this stay actually open? You download some videos and close it in a few minutes. It's not a persistent use case like a chat client.

youtube-dl is a 10 year old project. Where are all the great qt gui-s for it?

It's a CLI app, it doesn't need "an app" for it.

I think it's matter of usability and taste. As a programmer who uses CLI applications daily I still find GUI applications far superior to those tasks for which I don't have the CLI commands imprinted in my tactile memory. And I forget any CLI functions I don't use daily reaaallly fast.

$ man foo

Now tell me where the swipe-from-the-left and swipe-from-the-right and pull-down-from-the-top and long-press and double-tap and trippple-tap and pinch vertically and pinch horizontally and triple-finger tap for "modern" apps are documented?

I think we must be using different apps.

For example - re-encoding a movie file. I'm 100% sure it's much faster for me to type "<windows> hand <enter>" to start Handbrake, click open, paste the path to the file to the file dialog, and click convert, than figure out how to use ffmpeg command line.

OK, you got me at ffmpeg! By bash history and search history are littered with fighting that gem.

But youtube-dl, the subject of this post, is another matter. Using it is a simple matter of `$ youtube-dl <url-to-video>`, the former which is bash-completed after two characters and the latter which is a paste. Surely that's quicker than any GUI.

A lot of people prefer 1-2 mouse clicks instead of typing in dozens of characters, needing to memorize arguments and options. Try to download a specific resolution as a novice user. Especially if you are disabled and can't type easily.

I hope you never buy premise chicken stock from the store.

Everybody has things they are interested in and want to spend time on. But not everyone can do all of them.

> Where are all the great qt apps for it

This is really a valid question (not just for youtube-dl but for chat apps as well)... I guess the answer is : Qt being LGPL and the abundance of front-end webdevs

It is completely possible to sell closed source applications even using QT. ( It is all about how you link your QT libraries )

I think the main reason is abundance of frontend devs and quick to start using Electron.

And I don't get how you can be so defensive about Electron. It's technically inferior to literally any native solution such as wxwidgets or Qt. RAM usage, CPU cycles, Hard drive space... it's such a disrespectful stance on computing resources.

Because talking about it here completely misses the point. Yes, Electron has a number of problems, so what? This is an app that you open and close within 3 minutes. Open Video Downloader is a very usable software that doesn't have any direct alternatives right now to my knowledge. It's actually a good example of how a great, easily accessible UI framework can enable the creation of cross-platform apps that nobody did in those other "leaner" frameworks until now.

And by normalizing Electron we get even more of the same, instead of convincing people to learn better tools for the job. It's a race to the bottom.

Keep missing the point. Any tool used IS the best tool for the job until it runs and someone doesn't make a better app with a better tool. The guy is probably a JS dev and he made this as a low-impact side project. It's a really hard sell to dive into C++ or picking up some obscure framework with fraction of the community just for the sake of this (see "sad state of cross-platform gui frameworks").

It's like someone posts a phone video of a new rare animal species and you comment "A DSLR camera makes infinitely better video, it's much better suited for the job, we keep normalising bad mobile phone videos, people should use the right tool and carry a DSLR around".

The only good phone is a landline and it should be made of bakelite.

> it's such a disrespectful stance on computing resources

If it lets somebody accomplish something productive they wouldn't have had the time/expertise to do otherwise, then it's the best possible use of computing resources there could be.

Computing resources are a means to an end. Not an end.

Constantly providing an "easy way out" for problems in form of technically inferior solutions is not a good path to tread on.

So no one should ever do anything unless it is technically perfect?

That’s an even worse path to tread on.

No, nothing is perfect, but this is IMO a case of one being vastly worse than the other, with the only merit that it's "easier".

So use one of the many other gui front ends for youtube dl, or create your own? Post a constructive alternative here instead of just complaining?

Qt and wxWidgets are hardly native. Come on now. Electron isn’t perfect but if you are trying to build a good-looking/functioning UI for platforms that aren’t Linux (and thus have no UX consistency anyway, Elementary being an exception), it is a very viable option for lots and lots of devs. Especially web devs.

I get the hate at bad Electron apps but it’s also an unfair punching bag, IMHO. I would rather an app like this exist than not. And as a Mac user, I’d rather a good Electron app than some wxWidgets mess that still struggles with HiDPI in the year 2021, when every Mac I’ve owned since 2012 has had a high resolution display.

How is wxwidgets not native? They literally wrap native controls. Short of writing directly to a device frame buffer, you aren't getting any more native.

Qt is does indeed not use platform controls, but it is still a huge distance away of the insanity that is Electron.

Highdpi is also a solved problem on a lot of platforms already, and only really a problem in the first place if you use absolute pixel offsets or coordinates instead of extents, spacers and other automatic geometry tools.

> youtube-dl is a 10 year old project. Where are all the great qt gui-s for it?

> youtube-dl is a 10 year old project. Where are all the great qt gui-s for it

Here: https://github.com/MrS0m30n3/youtube-dl-gui

or here: https://github.com/jeanslack/Videomass

Another self-hostable option that runs as a server (and you access with a browser):

https://github.com/alexta69/metube

I was just about to ask about something like this! I looked at the page but couldn’t figure out if this allows you to watch the downloaded videos in the browser as well, does anyone know or if there is another docker/web app for that?

Well I could imagine running Jellyfin[0] next to this? Hooking up both programs to point to the same folder would probably get you pretty close to what you want

[0]: https://jellyfin.org/

Check my other reply, Tzahi12345/YoutubeDL-Material supports this. No affiliation, just started using it myself.

Similar project, but allows watching in the browser & downloading to your client machine:

https://github.com/Tzahi12345/YoutubeDL-Material

Another alternative: I made a small tool which allows one-click downloading videos with youtube-dl. No command line, no GUI.

https://github.com/baobabKoodaa/one-click-youtube-dl

I had so much hope when I saw "cross-platform", finally a youtube downloader my parents can use on their 8 year old laptops.

But alas, it's just electron. I guess they'll continue to use Newpipe on their phones, which has been working very well.

Edit: I just realised that my comment is a bit on the meaner side. While I absolutely detest the current trend of Electron apps I also realise that the ecosystem doesn't have any good options. QT can be okay if done right, but C++ is neither ideal nor approachable for Application development, especially for hobbyists.

Have you tried freetube? (I'm unsure if it's electron though)

Freetube uses Electron (from project README : https://github.com/FreeTubeApp/FreeTube)

We need to educate what browsers are capable of,

https://whatwebcando.today/

https://whatwebcando.today/files.html

Electron apps run just fine on my 8 year old laptop. So long as there's only a couple of them at a time, mind you.

Newpipe has been working well? Throttling issues. Takes too much time to load. Video is black for a few seconds when changing to full screen. Comments don't load sometimes. Only comment loads sometimes. It is fundamentally broken.

I built a similar thing a while back, but instead of electron it’s just an web server that exposes a simple UI form and downloads videos to pre-set folders on your server.

https://github.com/Capevace/youtube-dl-ui

Somewhat related self-plug: Self-hosted browser client for watching YouTube anonymously (Python):

https://github.com/user234683/youtube-local

It supports downloading all the raw formats (the video only ones, audio only ones, and the 360p & 720p integrated formats). More meant for watching than downloading, but some more advanced downloading features, such as merging audio+video with ffmpeg to get more downloadable qualities and auto-downloading options for playlists are planned.

Is this using the original yt-dl or the fork with more features? https://github.com/yt-dlp/yt-dlp

The original but the dev has it as a priority to replace with yt-dlp. You can use that now by replacing the youtube-dl binary with yt-dlp and renaming it and turning off auto-updates, but it doesn’t support some of the other features like SponsorBlock for now. The dev has PRs open to investigate that.

If I had just a bit more time I might try to contribute. In fact, I might actually see if I can help with the replacement of the engine and then let the dev decide on how to implement some of the extra features.

This past week I made/forked something similar for macOS only.

There was a GUI for youtube-dl I liked but never could get to work called Get-It (https://github.com/Kevin-De-Koninck/Get-It), and with many people switching to the actively-maintained fork yt-dlp, I decided to try using that as a base for making a clone with the latter as a backend.

I don't know Swift at all but thought I'd try it out to see if I could, and it seems to work for the most part on my end. I also cleaned up random errors I found in the code (like a rogue youtube link to a Grand Theft Auto 5 video?) and made things a bit more consistent, or at least I'd like to think so. Changed the UI and added a toggle to block sponsorships from videos as well, but not totally sure if that works all that well yet.

I'd love if anyone would try it out and report any issues they run into, it's been fun trying to fix it up!

https://github.com/jslpc/Swift-DL

THe youtube-dl gui I use is https://github.com/database64128/youtube-dl-wpf

The last update added the ability to use yt-dlp instead of the mainline yt-dl

I think it is windows only though

Yeah I think it is but this is a great Windows option, thanks for the share!

I made a very simple youtube-dl front-end that runs locally in a browser (flask, no javascript):

https://github.com/dvolk/lo2#readme

How does it manage to stay up to date? It's crucial for youtubedl which breaks regularly because youtube changed something and you now need the latest version.

The version my Linux distro supports is always helplessly outdated. But with conda I always get the latest version of youtube-dl.

Nice. I can't maximize the window, or resize it properly (minimum window height is bigger than my laptop at 1366x768).

Hope it gets fixed, good job!

Which seems particularly inappropriate given the GUI is web-based.

Nice job,I was exactly looking for this a few weeks ago. Do you support playlists so it would get all songs in one playlist?

From the features[1], it seems to support:

"Download multiple videos/playlists/channels in one go"

[1] https://github.com/jely2002/youtube-dl-gui#features

The words "cross-platform" caught my eye, but I don't see any screenshots of the program on macOS or Linux.

It's Electron, the Mac and Linux versions will look exactly the same.

That’s not always a given. It’s possible for Electron apps to have per platform styling.

It's using Electron, is there any reason to show three ~identical screenshots?

Not every Election App looks identical on each platform. Plus, it’s just a nice confirmation that the experience works properly on your preferred platform.

Sure, I suppose it's just that if something claims to be cross-platform, and is using a common framework for that, I'm happy to assume it's either exactly the same or the same modulo title bar, and not require 'proof'.

If it were my own project and I had a few different views/features to show off in screenshots I might alternate them (assuming there were some differences, or light/dark themes). But I definitely wouldn't show three copies of the same thing to somehow emphasise 'works on Linux, Mac, and Windows, seelookproof'.

> Sure, I suppose it's just that if something claims to be cross-platform, and is using a common framework for that, I'm happy to assume it's either exactly the same or the same modulo title bar, and not require 'proof'.

As the old saying goes, assumptions make fools out of you and me. If we are to assume anything, I always start with worst case scenario and work my way up to “everything’s fine” rather than start here. If I don’t see it running on macOS, I assume:

- it’s untested and may not work properly

- it doesn’t follow standard macOS UI conventions like drag and drop, which is much more pervasive in macOS than other OS and, when it comes to files, can work quite differently

- it doesn’t support operations like having files dropped on its Dock tile

- it doesn’t support the global menu bar and thus its keyboard shortcuts (if any) aren’t able to be configured via standard means — this is often important for accessibility

- it doesn’t support macOS’ built-in accessibility features, so can’t be read by VoiceOver or show large text via Hover Text

Once you go beyond the superficial, you realise that design is more than just how it looks but how it works — functionality, usability, etc.

All I want is the mildest proof that, at the very least, it has been tested to run on macOS. At that stage, I might put the effort in to check that those other aspects are also covered.

It isn’t my job to find that out; it’s the developer/vendor’s job to prove it so that I’m not wasting my time.

> But I definitely wouldn’t show three copies of the same thing

Of course you wouldn’t, why would you — that’s not even what I wanted to see. I’m only interested in seeing it working properly on my platform.

Most websites will show the platform-specific screenshot rather than all three screenshots. For example, check out https://code.visualtudio.com — on an Apple device, it shows the Mac version; on a Windows device, it shows the Windows version; I’m not sure if it shows something else on Linux, it may do.

I like this a lot! I use it for friends/colleagues who are too intimidated by the CLI. The old YouTube-dl GUI was abandoned and isn’t something I can recommend and the best fronted, Downie, is Mac only and costs money.

Also, the dev is looking at subbing youtube-dlp for youtube-dl, as it is more frequently updated and supported.

That's perfect. It is funny how this is better than youtube in so many ways. If only it could be taken mainstream.

> ...If only it could be taken mainstream.

A part of me actually wishes for utilities like this GUI app and the underlying youtube-dl to stay a tad under the radar, only to avoid getting them blocked somehow by the powers-that-be...i know that is selfish because at the same time i do like for as many folks as possible to have access to all the cool tools (after all i love to spread the gospel of open source software)...but, man, youtube-dl (and by extension, anything else built on top of it) has been such an awesomely amazing thing that i never want it to go away or get blocked, etc. Sorry if that sounds mean; don't mean to be. :-)

Love the app but somehow it's very slow? I have a 300 Mbit/s connection and it's downloading at 55 kb/s...

EDIT: apparently luck plays a part. I stopped the download halfway. Then downloaded anew, and got 80 kb/s. Then canceled and restarted again, and then got 5 Mb/s...

Youtube throttles download speeds.

I'm not affiliated with this project in any way. I just posted for publicity

Cool. Thank you very much. This ine seems the best I have seen so far.

A minor bug though: the "Open file" button is disabled, the "Show in folder" button just doesn't work. At least on my Office PC running Windows 10.

Really, really nice. Preview displays rating, duration, thumbnail, etc. for playlist and you can change individual setting for items of a playlist.

WOW - 100MB download for Mac!

However, once I installed it, it ran really well. Interface is smooth and nice.

That's electron for you. You can make some nice stuff in it but you're essentially downloading chromium and running a web app locally when using electron with the same downsides and upsides.

a bit OT but I'm curious what's current status and usage data for YouTube-dl and its popular forks (e.g. yt-dlc, yt-dlp)?

They all seems to be active to different degree(last commit is 2mth, 2w, 2d ago)? and not merging backing to each other?

Nice!

Are you planning to support all options?

Thank you for this! It is super valuable.

> package.json

Ctrl-W, bye

Thanks bro

Reply on news.ycombinator.com