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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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]
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.
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.
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.
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).
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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!
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.
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/
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’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.
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.
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.
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.
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 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?
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.
> 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.
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.
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.
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".
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
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.
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?
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.
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).
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.
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
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.
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.
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.
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!
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.
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.
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...
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.
https://i.imgur.com/yxlRTI8.png