Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: YouTube-DL GUI Powered by Electron (github.com/mayeaux)
142 points by mayeaux on July 2, 2019 | hide | past | favorite | 138 comments

Suggestion to author: allow pasting and downloading more than one link at a time, and selecting audio/video + desired formats.

Suggestion to everyone else: learn the CLI. Then you can do things like me last night. My wife collected a list of classical music videos she wants to play to our kid, and all I did was:

  youtube-dl -x --audio-format "mp3" --audio-quality 0 -o "%(title)s.%(ext)s" -a music.txt
to get the whole list turned into neat and nicely-named MP3s (like "Mozart - Eine Kleine Nachtmusik, K 525 Allegro.mp3"). Followed by:

  mp3splt -r *.mp3
to trim the silence from both ends.

I do batch downloads like these rarely, roughly once a year (though I expect it to happen more frequently in the near future). Because of that, I had both of the above commands stored in my snippets.org file. It's something I strongly recommend: store off-used CLI calls in your notes/personal wiki. It beats reinventing the commands a year down the line, or even trying to remember what tools did you use for that off job.

To preempt comments saying CLI is too hard for regular people: no, it isn't; they can learn[0], especially if you make them interested by e.g. showing them how to do batch jobs. But for the sake of the resistant, maybe the author of this GUI will upgrade it with option for batch downloads and format selection.


[0] - https://digitalsuperpowers.com/ is a nice book I read and can recommend. No affiliation, just curiosity, because the author is a regular HNer.

Ooh, I didn't know about `mp3splt`! This is super helpful, thanks for posting it.

> It's something I strongly recommend: store off-used CLI calls in your notes/personal wiki.

All of my bash commands from any terminal get piped into a separate, unified history file, copying some setup I read about in a blog a long time ago. It's an easy, dumb setup that just works. I've been using it for years without any performance problems, and if I ever get any, I can just archive the current text file and start over with a fresh one.

Having access to past commands is really handy and has saved my butt multiple times.

          $(history 1) =~ ^\ *[0-9]+\ +([^\ ]+\ [^\ ]+)\ +(.*)$
      local date_part="${BASH_REMATCH[1]}"
      local command_part="${BASH_REMATCH[2]}"
      if [ "$command_part" != "$PERSISTENT_HISTORY_LAST" ]
          echo $date_part "|" "$command_part" >> ~/.persistent_history
          export PERSISTENT_HISTORY_LAST="$command_part"

  # Stuff to do on PROMPT_COMMAND

  HISTTIMEFORMAT="%d/%m/%y %T "
  alias phgrep='cat ~/.persistent_history|grep --color'
  alias hgrep='history|grep --color'

Thanks for this. This solves my tmux / history problem. Commands from one open terminal were not available in the history command for the other terminal, if I had two terminals open.

Too tired to try it and port if necessary yet, but I'd like to ask: does it work on ZSH?

I've never used ZSH, so I don't know.

My instinct says that if you'd run into any problems, it would be with this line:

Maybe ZSH has a different API? Again though, I've always just used bash, so you'd have to try it and see.

You can even do fun things like transcode a stream into a format that omxplayer can handle and render a video straight onto a Raspberry Pi without having to download it (and without X11)

'omxplayer' '--blank' '--aspect-mode' 'stretch' <(youtube-dl -o - --audio-format m4a --recode-video mp4 'https://www.youtube.com/watch?v=MKNYsKwM6HI')

While I was still using my Raspberry Pi as a "media center", I wrote a small server using tornado that did this via a URL: https://github.com/filmor/rpi-media/tree/master/ytdld

I had a small javascript commandlet in my bookmarks that allowed me to start playback directly from a youtube (or any other youtube-dl supported) page.

You can also do that with the 'Play to Kodi' browser addon.

> To preempt comments saying CLI is too hard for regular people: no, it isn't; they can learn[0]

Hear hear.

It all comes together when the regular person takes a little time to learn the following three truths[0]:

* the output of any CLI command may be redirected to the input of any other CLI command

* the output template of 99% of commands give you structured, predictable JSON data/metadata on which to operate

* 99% of CLI commands have the same sane defaults and are required by the spec to have the same option syntax for flags

* CLI is CLI. Generating a random number in the CLI on OSX is just as safe as doing the same on OpenBSD, Raspbian, QNX, etc.

[0] Three because I'm starting from zero

I plan to make an 'advanced' mode that will allow people to pass custom flags, select file formats etc, especially given the large initial interest. Right now this was mostly a proof of concept and targeted towards nonsophisticated end users but if the project grows those things will definitely land in time, thanks for the suggestions.

No problem & good luck. I'm definitely not a target user, but my mom is. The Electron aspect is a bit painful though manageable, but as long as she could literally download the .exe, and the basic functionality of the product was simple enough (click to open, paste URL, click to save; optionally click to specify some advanced option; no tracking or telemetry whatsoever), I'd happily install it for her. I already installed her a standalone console .exe + ffmpeg, but it's slightly too painful to use[0].

(If you ever happen to grow the project to the point of offering different languages, drop me a line, and I'll give you Polish language translations.)

EDIT: Also consider auto-updates for your application; it would be best if it could update its youtube-dl dependency independently from the app itself. I don't like auto-updates too much (especially when they're forced), but as others point out, youtube-dl and YouTube are in a state of cold war; YouTube downloads tend to magically break every couple of weeks now, which requires users to update the youtube-dl script.


[0] - https://www.lesswrong.com/posts/reitXJgJXFzKpdKyd/beware-tri...

Thanks for the input. Yep your mom would definitely be a target user but even for myself the app has been very useful, when you know you have a nice GUI to play with it reduces the cost of doing certain fun projects that require quick downloads so it is nifty for everyone to have in their backpocket, and yes the .dmg for OS X is ready and I'll have an .exe file out relatively soon too.

Auto-update will definitely be a feature it's quite easy with the youtube-dl package I'm using.

First thought on this project: hey, why electron yt-dl works perfectly from the command line, I type the programm, paste the url. Second thought: might be nice for selecting from the myriad of options. Well...

You've just summed up the gui/command line dichotomy.

It's something we could do better at bridging the gap between.

Tbh things like this, a gui front end for a terminal app seem the best way forward. I don't know why they aren't used a lot more in open source, it just seems to match up so much better to the open source model of a random person developing a project and no one taking over when that person loses interest. The front ends are the sexy bits where you get more churn but also more interest. The boring back end doesn't attract, but also doesn't need so much attention.

I suppose you could argue we do it at the library level, I still think there's room to do it at this level also.

> the front ends are the sexy bits

For a lot of people this isn't true.

I think for web developers, making guis is fun (why this is done in electron). For a lot of non web developers, making the actual tool is the fun part. Having to then fiddle around with some gui feels less like programming and more like a chore.

Actually I hate doing frontends way prefer to work with serverside code than play with the DOM, but I recognize that a good frontend is super important to the app to allow people to reason about how it works and to help them through the process, but for my 2c I would way prefer to tinker with backend code all day :)

Ok, can we agree that back end and front end appeal to different kinds of people, and the lifespans of front end and backend are different.

You can't script this GUI. You can't use Cron with an interactive GUI. You can't parse stdin/out/err.

Each have their pros and cons. I'd say what makes most sense is a library with frontends (CLI, TUI, GUI, (web)socket, etc)

In this case I wouldn't need a GUI with Electron. All I would need is a Firefox extension for youtube-dl (or the hypothetical library). Why keep reinventing wheel? Hence library.

One annoying thing with CLI is defaults. You might wanna set defaults (in CLI often used in an alias). So I end up managing a large alias list but what if I use more than 1 shell depending on machine? What if the machine does not use Git to sync such files?

"You can't script this GUI. You can't use Cron with an interactive GUI. You can't parse stdin/out/err"

No but you can script the underlying youtube-dl so with the gui front end you get the best of both worlds.

Re defaults, that isn't an inherent shortcoming of terminal apps. Theres no reason why 'youtube-dl url' shouldn't just do the 'right thing'. I agree it's a common problem though.

> Theres no reason why 'youtube-dl url' shouldn't just do the 'right thing'.

The error in your reasoning is that you assume the existence of a singular right thing. Software that attempts to just do the right thing tends to suffer from what I call Overly Clever Syndrome. I hate waiters or store clerks that second-guess my motivations. Why should I like software that does the same?

That said, `youtube-dl $url` will download the pointed-to video in the best available quality, so that's a pretty decent default.

I put 'right thing' in inverted commas because I know how slippery it can be.

Gui apps have defaults too, this isn't a problem unique to terminal apps. I'll go further and say GUI apps suffer more because they tend to design around a default and have many fewer non default options, in the name of being easy to use. Terminal apps on the other hand 'suffer' because they don't make enough assumptions about how it is to be used.

Suffer is very much in inverted commas though, sometimes you want to do that niche thing, and having something that makes no assumptions about how it will be used is great. On the other hand having to read a manpage for the simplest of things is not so great.

> Tbh things like this, a gui front end for a terminal app seem the best way forward. I don't know why they aren't used a lot more in open source

Elitism. A lot of people in tech have gigantic egos and believe they are better than everyone else because of their arcane knowledge, so they have no desire to see anything become more discoverable or easier to use.

Whereas non-tech people would run around like headless chicken if asked to build anything. Forget discoverability.

It's not an ego issue - I doubt any tech worker is happy when dealing with non-discoverable software as a user. But connecting this experience to building your own software, and learning to design things to be discoverable by default (because in a typical job, if you don't do something right the first time, it probably won't ever be done right), is hard.

I think its more:

A) power users having different priorities to light users. That tool you use every day, you probably use keyboard short cuts, know all the flags. The tool you use once every 6 months, you probably scan the menus and check the man page. Open source tends to be focused more on the power users, mainly because its probably power users that made the thing to start with.

B) open source tends not to be a 'product'. There aren't focus groups and usability testers, the first releases are Alphas and Betas so tend to attract technically minded people that find their way around less discoverable interfaces.

I guess for the ever changing sea (more like the lakes of Google and Vimeo) of video-sites, the backend actually matters a lot... And (this GUI being a prime example- while not really even featureful): most CLI (instead of library...)-wrappers show it. They're a bunch of dialogs for selecting options - wow. I wouldn't care if you propose developing the GUI separately (basically for wrapping any CLI, you could develop a generic wrapper, reading in declarative configs...), but the kind of execution demonstrated here is probably necessiting the installation of 1 GB of electron-crap (say hello to the reusing world of require('shebang-regex'))

I liked the "Commando" GUI in the Macintosh Programmer's Workshop:


Using it is like pulling up the manpage while typing out a command, but interactive. Once you're done formulating your command, it runs in your worksheet and you can modify it and re-run it if necessary, just like any other command.

Even being someone who uses the CLI, now that I have this app I will probably rarely use the CLI, it's just nicer to see things visually as to be able to reason about them. Also selecting the directory etc is something way more easily done via a GUI than the command line. There's a reason why operating system manufacturers created a GUI and we all use them today, they fit with our brains much more than just using a terminal.

Not everyone is familiar or comfortable with the command line.

A lot of my friends don't use youtube-dl for this exact reason. They end up messaging me, asking me to download files for them.

Why not just create a simple phone number with twilio that they can text a url to and then it fires a script to download that video and upload it to s3 for them? Shouldn’t take more than an hour IMO.

Mainly because I actually like talking to my friends, and I'm often interested in whatever video/music they want me to download for them.

I have no desire to automate my interactions with my friends, especially for something that's easy enough for me to do and only takes a minute of my time.

You could just look at the logs to see what kind of stuff they download. And since they know it’s automated they will likely download even more stuff. If you see something interesting then maybe you can start a conversation with them at that point.

If it wasn't for the copyright infringement this wouldn't be a bad business idea.

One video per day is free - if you want extra "credits" pay for it on the website.

It doesn’t really matter, if you get a dmca takedown just delete that file. But I doubt you will, especially if it’s just your friends hosting it.

I understand this too, but being on HN, familiarity with the CLI probably can be taken for granted. For all the other people this will stop them from using shady sites, but even some of them might like to have some more options included in such program... For the current feature-level there is 0 reason to do a bloated electron app - just do your 100 lines of code with tray integration for all the major OS (with a GUI) (Java might even have systray integration)

There's already a bunch of websites that do this if they can't use youtube-dl -- why are they messaging you when they can literally go to one of these sites and paste the URL in to get the video?

If you’ve trained a computer illiterate person well, they will not go to sketchy ad-ridden websites and download files to their PC and double click them.

Name 1 which works flawlessly. No ads. On a side note, is it possible to port this CLI program to Android or web? My mom needs a downloader and the Firefox ext which I used till now , doesn't work all the time.

install termux, install youtube-dl, define a "handler"-script, share the link with termux

You made me realize I accidentally used the worst audio quality all the time.

I thought higher number = higher quality but then I had a look at the manpage again...

I wish the installation was easier. It is reasonable to explain someone to write "youtube-dl -x <link>" to download music from youtube...

But having them installing ffmpeg and python, manually copying some exe to a safe place, and adding that as a enviroment variable really cuts the interest off.

Might be the use-case for Chocolatey or something like that, if more than just youtube-dl is going to be used in console.

(Dunno which package managers are alright in Windows.)

Chocolatey is the way to go. Once you have it installed, it's just `choco install youtube-dl` and `choco install ffmpeg`.

This is how you get Chocolatey: https://chocolatey.org/install.

Chocolatey also bypasses all the dark parterns of download websites which is a big plus for a non technical user. I wish Microsoft would take it over and integrate it in windows by default.

You're describing the Windows Store.

Except the windows store was the toll protected, limited privilege applications, had to be developed for windows store, rather than a way to download and deploy any msi for major existing software.

I like https://scoop.sh/

    scoop install youtube-dl

That's because you're using Windows, which is really, really not designed with scripts in mind.

Point to Ubuntu in the Microsoft Store. Python is preinstalled. You may need to install Python's package manager (I'm not sure does it come preinstalled) with "sudo apt install python3-pip". Install it from Python's package manager with "pip3 install youtube-dl".

You could technically skip Python's package manager by just doing "sudo apt install youtube-dl", but updates are slow there, and you really don't want slow updates with this tool ("pip3 install --upgrade youtube-dl"). I'd argue that three commands are way easier to explain than installing two binaries and clicking around far too many times, especially because youtube-dl needs to be updated on a regular basis in order to work properly.

Did you honestly write this down thinking it was remotely any easier?

Then the alternative? Absolutely. The alternative requires finding the latest version of Python, installing it, modifying the environment path, finding the binary for youtube-dl, installing it, and only then figuring out how it works.

"Execute these commands only once and then just type youtube-dl https://example.com. If something breaks, run this command to upgrade the script and retry." If the target audience is someone who you think will feel comfortable doing youtube-dl in a terminal, you may as well point them to the total of three other commands to set things up.

AFAIR youtube-dl had an .exe build, I remember setting it up for my mom; it boiled down to unzipping an archive and telling here to drag URLs onto this icon. And the FFMpeg part; that was a PITA, and something she wouldn't have guessed on her own.

> Windows exe requires Microsoft Visual C++ 2010 Redistributable Package (x86) and does not require Python that is already embedded into the binary.

Yeah, that makes sense. Things have changed since last time I went through that pain.

Funny how I've been using vb, python, perl and bash scripts. Windows for the past 20 years. I suppose that didn't happen?

Why do people who use Linux automatically think you cannot use scripts or there are no scripting languages on Windows?

I plan to package platform specific FFMpeg with the app especially now given the large initial interest. Then once I package everything for the different platforms via Electron it should be as easy as installing any other application an end-user would install, that's the hope.

snippets.org seems to be some sort of iGaming site. Is there some other site you use for storing snippets?

:) `snippets.org` means that TeMPOraL is using org-mode[0] to organize the content; it's not a website.

However, I would say use Git and just sync your stuff to a public/private Gitlab/Github repo depending on your needs. That's how I organize most of my public configs.

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

Ohhh, right. Thanks! I'm a vi person myself. :)

Sorry for that. 'danShumway is correct - it's a snippet file called snippets.org, i.e. it's written in org-mode.

When composing my comment, I wrote a couple words about Org mode, then realized it's off-topic and deleted them before submitting the comment. I fully intended to leave just "snippets file", but forgot to remove the ".org" part.

I know this is quite selfish but the more accessible youtube-dl is, the more likely Google is to see it as a business threat, and the more likely they are to add some sort of content DRM. Just something to think about

It's coming regardless, as soon as Google can get their CDN efficiency to a point where they can do on the fly encryption of the stream (or post encryption insertion if they can figure out a way to do the key management) with the advertising embedded they'll push the switch anyway, to prevent ad blocking.

That capability is truly scary. Once the ads are baked in and everyone has that capability, there will be no escape. It'll be worse when they DRM HTML itself and force the ads down our throat.

It feels like we've backslid by miles and miles since I first got on the Internet in the late 90's. I no longer like this Internet.

I agree, ideally youtube-dl would remain obscure, but YT has been on to it for a long time. It's somewhat of an arms race right now. I have to update youtube-dl every few weeks or it will simply stop working.

I would not be entirely suprised if Youtube one day just requires actual browser DRM to work at all. That would likely break every single smart TV out there, which is probably the only reason why they haven't yet done it. However, as they progress further on their path away from amateur content towards corporate-only content, I'd say there is a decent chance they'll pull that switch eventually. And die shortly after, of course.

Which also sounds like a good reason to make copies of everything interesting on YouTube now, while we still can.

Indeed. I'd go further and say that it's generally a good idea to make backups of all the cloud stuff you're using. The assumption that it'll always be there is fundamentally flawed. While there might well be outliers, companies who keep content archived for virtually ever, most platforms will go away at some point.

Personally I think Youtube is a likely candidate for this. They may very well just remove all "legacy" content one day. They have absolutely no idea what to do with the platform, except offer it to music companies to feast on. They're at war with the majority of their content creators, I'd be very surprised if they didn't go for the nuclear option at some point - maybe after a large legal scandal...

I agree, YouTube-Dl already has 50k stars on Github, it's certainly not obscure anymore. Although I'm not suggesting breaking the TOS if people are going to be using it to archive content then the best bet is probably to have the content archived as quickly as possible rather than trying to keep youtube-dl lowkey (ship has sailed) so as to not trigger DRM from YouTube

That's exactly what I do, I make a copy of every video I watch.

Frankly I wouldn't mind making a browser extension that does exactly that, and then if you go back to a video you've already downloaded before it plays it from disk as opposed to from the network. Something I've thought about.

I'm inclined to start doing it too; I'll try to wire something up this week that saves to my NAS over LAN. From time to time, I browse my "Liked" / "Favourited" videos on YouTube to find something I've seen years before, only to discover that it's gone.

> That would likely break every single smart TV out there, which is probably the only reason why they haven't yet done it.

It wouldn't, support for Widevine has been mandatory in order for Google to let TV manufacturers have a YouTube app for about four years now, and if you play back a Google Play film on the YouTube application on your smart TV it's already using Widevine DRM.

But it probably isn't used in the YouTube apps and using it would require pushing an update. Smart TV manufacturers are not famous for pushing updates promptly.

> But it probably isn't used in the YouTube apps and using it would require pushing an update.

It is used in the YouTube apps, for playing back Google Play film purchases and rentals inside YouTube. Google does not allow YouTube to be installed if the YouTube apps cannot call the requisite APIs.

> I would not be entirely suprised if Youtube one day just requires actual browser DRM to work at all.

maybe not at all, but I definitely can see them offering the option to (some?) authors.

Maybe they already have? `youtube-dl` has been breaking a lot for me lately. I've been using the Fedora repo build for many years and don't remember it ever breaking, not once. Now in the last couple of months it had suddenly stopped working 4 or 5 times, which forced me to install the official build from `pip`, which is updated more frequently.

youtube-dl is one of those rare programs that you shouldn't download from a repository. Do this instead:

- Download from the project page and put it anywhere in your path (it's a single file)

- Subsequently do 'youtube-dl -U' whenever you want to update. It updates itself in-place with the latest release (there's usually 2 or 3 released per week)

Yes. That!

I quickly learned the difference. Downloading from YouTube breaks. No distro update. But updating only the script is quick and easy.

Initial installation is also very easy. Two one-line recipies to install it are provided. One using CURL and one using WGET.


I have been using it with ffmpeg on a google pixelbook on cruoton for over a year and love it.

What's the difference to installing 2-3 updates per week over the distro? One should be installing distro updates daily anyway.

Distro repositories can't keep up with the number or timeliness of updates. When youtube deploys an update that breaks the tool (happens on a semi-regular basis), you want access to the fix ASAP.

You are right and there is nothing selfish about this.

Better few than none.

For me I think the best UI for YT-DL would be in the context menu in Firefox.

This is where I am most often when I see stuff I want to use it on and while I always already have a terminal window open, it would be nice not to have to switch windows.

I already have a few different configs and aliases for getting stuff in the forms I really want. All I need is an even easier way to pass the URL in and trigger the download.

Being able to right click and get there would please slack me to no end.

Most solutions I've seen to this require some kind of external daemon to be running that takes care of launching ytdl for you (since most web browsers don't allow extensions to run arbitrary commands.)

Firefox _does_ have support for running this daemon-like-thing for you using Native messaging[0] though.

youtube-dl-firefox-addon[1] seems to employ this, so perhaps give that one a try?

[0] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

[1] https://github.com/akhilkedia/youtube-dl-firefox-addon

Just my 2 cents:

I've been using a combination of firefox/chrome with youtube-dl/mpv+youtube-dl for a while

This comes very handy for playing high quality youtube videos on low end machines or downloading audio+/-video directly from youtube.

On the pre-webextension era of firefox/chrome , "open with" addon was the perfect fit.

Now, a special native messaging app needs to be installed to launch mpv/youtube-dl

"Open with" addon solved this by a python script (that obviously required installing python, and few other steps)

I decided to create a new tool to make this step easier and faster on windows: owclauncher[1]

Basically a lightweight native messaging host for "open with" addon: it is not running on the background, and only started (and immediatly terminated) by the browser when passing a command to any other program

You can check and compile the source code or the .bat windows installer/uninstaller

[1] https://github.com/mbooga/owclauncher

Hey wow! This is exactly the info I needed and it's for the platform I use.


I have this: a browser extension (and an Android share option), a web server to consume the URLs thus clicked/shared, a database to track state, and a cron job to actually launch the download. It's a bunch of ugly hacks, but I can just right-click or share a video, and have all the rest happen automagically.

I'd love to replicate what you've set up. The web server and from job doesn't sound too difficult, but I'm confused about the browser extension and Android share option. I'd be very grateful if you could elaborate further on that.


You have been warned ;) It is horrible - I slapped that together to scratch my itch and been planning to rewrite ever since. Perhaps now is the time. https://github.com/Piskvor/webfetchface

In essence, the core of the whole thing is a single SQLite table, with rows of URL+status (and some metadata).

The web interface lists these, and provides a form to insert more rows. There is no ACL, my instance is only secured by htaccess. (I have specifically chosen to use a web server, as I'm sharing the URLs from multiple devices, but I want to download them over my home link and save to my NAS.)

The cron job reads the table, fetches rows that are status=queued, calls yt-dl to download them, and updates their status accordingly (with some fallbacks and error handling).

There's some extra stuff - like using ffmpeg to make thumbnails - but the basic operation is extremely simple.

(Browser extension and Android sharing option do the exact same thing as the web interface: post the current URL through the web insert form. Those are optional, but allow me to add URLs without extra steps. The browser extension is installed unpacked, through developer options, and has the URL hard-coded. It works both in FF and Chrome. The Android share option is through https://play.google.com/store/apps/details?id=ch.rmy.android... , making a HTTP request directly - I'll add a README.)

Yup. Me too! Did someone make something like this?

The alternative I'm considering is a script for my WM that essentially does "CTRL+L, delay 500ms, CTRL+C, append to a rolling 'to yt-download' list file".

I did something like this a couple of months ago. I wrote a simple firefox extension which adds a button near the url bar which calls youtube-dl to download the current URL on a predefined folder. It needs an intermediate "helper" which is registered via the Windows registry (just make a key for it). All the helper does though is just call youtube-dl.

It sounds complicated but i had never written any firefox addon at all before trying it and it took me less than an hour to write the entire thing just by following the docs. The biggest change was switching from regular firefox to developer edition so i can disable signature checking for addons (the regular firefox doesn't allow that), but so far all that meant is that the red icon globe is now blue and i get more frequent updates.

None of that is available publicly though since it is very configuration-specific - and really all it does is to call 'youtube-dl' - but it is easy to replicate. Also learning to make some "personal" addons might be helpful in the future, similar to how you customize Emacs or Vim.

On firefox/chrome/opera for windows, you can do this easily with "open with" addon +/- owclauncher

I'm always weary about having timers in a script, because it often turns out to not be the correct amount. What about something like:

- bookmark url in a specific "YouTube-dl" folder

- watch tht folder from a daemon

- when the folder changes, do the stuff automatically

I'm sure there's a way to read bookmarks from outside the browser ?

I don't like timers either, but that seems to me the most direct way of exfiltrating the URL of the tab I'm currently looking at. Unfortunately, browsers aren't exactly interoperable.

Bookmarks don't seem that easy to exfil either. Firefox for instance (just checked) stores bookmarks, along with browsing and download history, in an sqlite database, that it keeps locked, so sqlite3 won't read from it. Maybe there's a way to force-read that database, but I haven't figured it out yet.

Here's an alternative idea I might actually go for: a systemd service[0] on my NAS in my home LAN that accepts links over the net and feeds them to youtube-dl. It could maintain a database of links already downloaded to avoid unnecessary redownloads. Then I could use an extension to simply send requests to an URL in my LAN.

My perfect UI would actually have this integrated with the Like button on YouTube. Click Like, it schedules a download. This is because there's plenty of videos that I wanted to get back to after few years, only to discover them gone (account banned, video removed, copyright bullshit, etc.).


[0] - Or something. There must be something in systemd that can be used to listen on a port, feed requests from it to a script, and reply with the output?

If you're going to go with Youtube's Like, you should be able to use the API (https://developers.google.com/youtube/v3/docs/videos/list, "my liked videos") and get the results you want there. The advantage of using Youtube's Like is that you can use any player from anywhere to do it.

This wasn't for youtube-dl, but a long time ago I used to have a somewhat similar system using a simple named pipe. Write the URL to that file, one URL per line; a simple ksh (back then :-) ) script read it on the other end and did its magic. The cool thing about it being that all you had to do was echo $url >> ~/.dl/queue.txt .

There is much direct and easier way to pass a link or the current page's URL to an external program using "open with" browser addon + owclauncher (https ://github.com/mbooga/owclauncher)

Didn't try this myself yet, but if you search FF extensions for 'invid' you'll find there are a bunch of extensions related to invidio.us which is like youtube + download button, and more. So there might be something to your taste there.

This level of integration is possible with another browser and normal youtube-dl: qutebrowser.

hmm for elinks i use a script i made.

xterm -e yourube-dl --restrict-filename -o "~/downloads/%(title)s.%(ext)s" -f "best[height<=?1080]" $1

the height means no bigger than 1080 but if 1080 does not exist go to the next best down. i have a virtual desktop(tiling manager) that my downloads download at visually like wget youtube-dl and thats why i use xterm -e keeps them out of the way and trying to draw ontop elinks. the terminal automatically closes when done.

Side note: as a daily user, youtube-dl is such a fantastic piece of software. It's one of those tools which, once you have it, you wonder how you lived before.

Agreed! But sometimes going to the CLI everytime is annoying which is in part why I wanted to build a GUI for it :)

Interesting, since I always have at least one terminal open, but opening an Electron app takes 5-10 seconds.

I just added it to keybindings in qutebrowser.

Especially once youtube switched to not serving the formats they used to and using newfangled codecs not supported by my old computers. youtube-dl is my only way to view youtube videos on most of my computers. Luckily it's easier to get ffmpeg builds that support transcoding from new codecs than it is to get youtube videos to play.

This seems harder to use than the command line tool

I predict, that once youtube-dl becomes easy-enough to use for the masses, YT will shut it down in one way or the other.

The user-facing business model of YT is quite simple:

> You get to see great variety of videos, but have to watch ads every now and then.

So from their perspective, youtube-dl allows you to steal the content w/o giving anything back to either YT or the creator.

To make this fair/sustainable youtube-dl user would either (A) have to tolerate advertisements in the downloaded video, or (B) pay a fee for each downloaded video.

I'd prefer for youtube-dl to stays small enough, that we can continue to freeload a little longer ; )

What if you're downloading videos from someone who has been demonetized?

This is not just about the content creators. Operating YT as a platform is far from cheap. I bet YT is most concerned about their own bottom-line.

I use youtube-dl regularly, through mpv. What I'd really like, is a minimal youtube search, in-terminal or a minimal gui. Then I wouldn't need a browser to use youtube at all; I dislike having to rev up a 1000mb browser just to find a video and copy its address.

Actually, now that I think about it, I can't remember if I've tried a text browser, might be bearable, though images of videos are sometimes helpful.

> What I'd really like, is a minimal youtube search, in-terminal or a minimal gui

It exists! It's called SMTube but don't let the name confuse you, as it works with a lot of media players, including mpv:


mps-youtube is quite nice: https://github.com/mps-youtube/mps-youtube

(note that by default it only shows music videos, but it's easy to change: https://github.com/mps-youtube/mps-youtube/wiki/Troubleshoot...)

yourube-viewer thats for search download or stream and can sign in many as well as many other function. it is terminal only no images.

Have you tried Minitube?

I used a modified version of this [0] (modified [1]) running on my home NAS and an iOS Shortcut to easily be able to "share" any webpage that has a video on it to a Siri shortcut that makes an API call back to that docker service. It will automatically download it for me and drop it wherever I have specified. I can then process those files later. It's a great way for me to grab a video I want while I'm on my phone. It can even handle queuing of videos so I can share multiple in a row if I want. I've found it quite useful.

It's no replacement for the CLI but it's better than copying the url, opening my ssh client, connecting back, navigating to the right spot, running youtube-dl, waiting for it to finish (this is the worst part), then closing my ssh app, and moving on with my life.

[0] https://github.com/hyeonsangjeon/youtube-dl-nas

[1] https://github.com/joshstrange/youtube-dl-nas/tree/https-fix

Why not just use Youtube-dlg?

Does everything it needs to and doesn't require you to use electron.

I tried to install it but I couldn't install WxPython3 via SourceForge so I couldn't get the deps to work. Plus the maintainer of that app doesn't care much for supporting OS X and Linux (basically tells people to just go use Windows) so I wanted to use Electron where I can package an app for all platforms.

I'm a bit ignorant of the details b/c I haven't touched web stuff before. But on a high level, how does a Javascript/Electron app wrap-around/bundle-with youtube-dl - which (looking at github) is a python app?

Or does youtube-dl need to be already be pre-installed on the system?

Electron is a small Chromium browser that can interact with Node.JS, youtube-dl is packaged with this app as a node package manager dependency. The youtube-dl binary is downloaded and then called via a child process, let me know if that clears things up for you.

So you need to have the python runtime installed for this to work? Or is that downloaded as well?

I was just thinking I could for instance make a similar JavaFX crossplatform GUI on the JVM, but I'd have no idea how to call the youtube-dl python code. So I'm just curious how Electron solves that problem :)

No you just need the prereqs to run node, the binary comes compiled already

Oh okay with precompuled binaries then that's not so crossplatform. Thanks for clarifying :)

Yep seems like dlg also has config options (flags passed to youtube-dl) unlike this app.

As a sidenote I didn't know what you were referring to initially because the executable is named youtube-dl-gui...

Not to mention youtube-dlg has a nicer, more powerful UI.

I hadn't heard of youtube-dlg. I tried to install it and it looks like it's still Python2 :(

I often had to update YouTube dl in the last months.

I hope YouTube is not coming up with a solution.

Looks really interesting, thank you for sharing!

How does it compare to jDownloader (jdownloader.org)?

It can analyze the clipboard - when I paste a YT link it asks me if I only want the video or the whole playlist.

I can choose from formats and I can choose to only download audio if I'm not interested in the video or want to save some space.

It has a reconnect feature for the router to reset to get a new IP and much more really cool things.

Suggestion to author: as this is presumably intended to be a user-friendly front-end, consider providing installers.

I just tried installing on windows following the README and gave up after fixing npm proxy issues and encountering multiple other errors afterwards. I could fix it, but I don't have the time to investigate.

Anybody who can fix it, likely won't need a front end like this.

Yup I plan to add installers for each platform, I just finished this yesterday and wanted to share it with people so I fired it off. Happy to work through the errors you ran into if you want to open an issue on GH but yes, installers will be coming pretty quick thanks!

Thanks, I already have that; my suggestion was for the repository in the OP.

I've had a good experience with youtube-dl-interactive. It's a CLI tool that allows you to choose the quality/format from a menu without having to first list and choose from every possible quality permutation.

Extended search with previews will be great and playback in external player will be great features to add.

But anyway, Youtube brakes API too often and maintaining any of YT apps is very painful.

I'm going to add functionality that makes it such that the latest version of youtube-dl is always installed, so as long as youtube-dl works the app should work too.

Could I paste a bunch of URLs and it would create a queue?

If you have a bunch of urls, paste them in NimbleText, a fantastic utility to combine a list with a pattern, and create a bunch of command lines (syntax is trivial: "youtube-dl $0")

Use chocolatey to install youtube-dl CLI as a self-contained executable.

At the moment no but it does handle downloading playlists/channels correctly.

wuff... first rule of youtube-dl is you don't talk about youtube-dl!!!

But nice work. I just hope it doesn't bring the ire of Google

Skimming the code I see main.js hasn’t got a single semicolon.

If you want to invite others to contribute, you may consider adopting a more widely employed js code-style.

This seems to be written in a very personal, opinionated and unconventional way.

Writing personal projects in a personal way seems just fine to me :) Looking at that file it's very obvious what's happening after just a cursory glance. I'd much prefer code that's very easy to understand without semicolons than the opposite.

Even though people have downvoted you, personally I agree with you, I haven't added any semicolons to main.js though because that file was automatically created in the original project I forked, if I ever have to edit it I will add the semicolons as I'm there but I haven't touched that file yet.

That file is a copy of a stock one from the quickstart guide: https://github.com/electron/electron/blob/master/docs/tutori...

Might as well die on the hill of tabs vs spaces or single-quotes vs double-quotes or trailing commas or space after function name.

More useful advice would be: use Prettier and ship a .prettierrc so people can trivially transform their contributions into code consistent with the rest of the project.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact