A cross platform front-end GUI of the popular YouTube-dl written in wxPython | Hacker News Reader

A cross platform front-end GUI of the popular YouTube-dl written in wxPython

github.com

136 pointsdsr1265 comments

Open articleView on HN

That project is abandoned.

There is an ongoing fork called youtube-dl-gui: https://github.com/oleksis/youtube-dl-gui

And an alternative called tartube: https://github.com/axcore/tartube

A cross-platform GUI for YouTube-dl (https://github.com/jely2002/youtube-dl-gui)

429 points|ducktective|2 months ago|151 comments

https://news.ycombinator.com/item?id=28478603

Another alternative is plasmatube[1] that is integrated with invidious and shows the youtube comments, make searching possible and show the video descriptions.

[1]: https://invent.kde.org/plasma-mobile/plasmatube

Came here to recommend the jely2002 project. You can swap out the YouTube-dl binary with the fork if you want (you need to rename it) and the dev is looking into implementing features from the fork into their project. Really good for people who need to work with less tech-savvy coworkers who need to download video files

It seems to me like youtube-dl is also abandoned.

yt-dlp[0] is a fork with additional features and fixes. It is also actively maintained.

[0]: https://github.com/yt-dlp/yt-dlp

Ever since youtube-dl was removed from Github, it seems like they gave up on the project.

youtube-dl works right now, so not sure if this is a fair thing to say. But you might have more insight than me. Maybe they realized that becoming a famous project is only a detriment to their mission

Someone mailed the maintainer, and received a reply that he currently has "[..] no free time to spend on youtube-dl as I'm busy with work, ongoing renovation and other post-relocation stuff." [1]

[1]: https://github.com/ytdl-org/youtube-dl/issues/29965#issuecom...

Not sure if this is something that affects yt-dlp but youtube-dl takes something like 5 - 10 x as long as watching the video for me now.

It works only as long as you don't care how long it takes to download a video. youtube-dl has had a problem with bandwidth throttling on Youtube for some time now. yt-dlp does not.

yt-dlp is a very healthy project with a friendly community, and featurewise is just a better drop-in replacement for youtube-dl. obviously it's building on years of work that went before, but seems to me like the torch has been passed.

Another alternative: I made a tool which allows one-click downloading videos with youtube-dl (no GUI, no command line). Here: https://github.com/baobabKoodaa/one-click-youtube-dl

I use yt-dlp [1] ... so far so good.

1. https://github.com/yt-dlp/yt-dlp

In other news, the new Google Drive for Windows also uses wxPython as its Desktop GUI framework (wxPython is a Python wrapper for wxWidgets, a cross platform UI C++ library).

https://www.google.com/intl/en_au/drive/download/

I made a very simple web UI (single file flask, no JS) for youtube-dl: https://github.com/dvolk/lo2#readme

I'm curious what is the reason for a GUI for such a simple utility? The command line for this kind of tool seems like the perfect interface. Just copy a URL, paste it, press enter. No buttons to press, etc.

People have different workflows, for some is easier to have visual aid of how the tool works and what options are available.

It's handy for people who are not comfortable with the command line, no matter how simple it is. In addition it allows one to convert to mp3 etc.

The number of people who might want to download something from Youtube & co is significantly larger than that of people comfortable with the cli.

I won't criticize someone for making more interfaces for this software, but I like the prospect that more people have been and will be motivated to learn about command line interfaces in order to use powerful software like youtube-dl.

> I won't criticize

> but

please stop gatekeeping

> motivated to learn about command line interfaces in order to use powerful software

many people never get basic tech literacy. i think we’d benefit from not simply assuming others have (or could have) access to the same resources, time and patience that we had. i think you probably mean well but your statement, which sort of implies that people say “I am choosing not to learn the important skill of using the command line!”, just comes across as ignorant and naive to me

Tech literacy would help a great deal saving our democracies. Nobody needs to know command line, but to be able to tell if you're on a Russian disinfo website or a legit source of information is also (but not only) a matter of tech literacy, so I think OP is on to something here.

Tech literacy isn’t using a CLI. Get over yourself.

> Nobody needs to know command line

You're replying to a tangential “continuing the conversation”-type comment as though it were a rebuttal in an argument. It already agrees with you.

>Tech literacy isn’t using a CLI. Get over yourself.

Unnecessarily hostile. We need less of this.

Hint: Being a jerk to people online using a random account makes you look like an asshole.

Wasn’t a random account. When I’m an asshole, it’s under my own name, thanks.

I love the command line just as much as the next guy, but I could appreciate a gui program onto which I would drag and drop links from the url bar as i’m watching a video, and where there would be zones like “save as video”, “save and convert to mp3”, etc. And it would also take care of queueing things up.

I couldn’t care less how those zones are defined and configured, could be a configuration file for all i care, but the end result would be much more potent than copying and pasting into terminal and then making sure it’s quoted or escaped properly.

Most people have no idea about how to use command line and it's fine.

OK, but if someone needs something like this for work (believe it or not, this stuff is faster than the official YouTube tools for downloading videos), expecting them to learn the CLI, install the libraries, figure out the settings, is a lot to expect. Especially if a Frontend exists. And on Mac, installing it isn’t a big deal (tho for CLI averse people it is) but it is more complicated in Windows (especially for people who don’t use a shell everyday).

I’m a huge fan of good CLIs. I’m also a huge fan of GUIs. Why require people to learn something just to use a video downloader?

GUIs were invented for a reason. They allow an intuitive and spatial understanding of software, and while they create limitations in some areas, they remove limitations in others. For example, I think the benefits are obvious of offering a native save dialog for where to download the video, rather than requiring the user to specify a hand-typed or copy-pasted path.

Even for people who know how to use the command line, most of us still spend the day in a graphical desktop environment, and having a program that integrates with that environment is very valuable.

I always have to look up the switches, there's quite a few. If you paste an URL it does one thing, it can do many others.

An interactive UI allows for more fluent authentication, choice of resolution to download, filename, etc. Default values can be modified instead of being specified from scratch (filename again). Other benefits I'm not thinking of off the top of my head.

> Just copy a URL, paste it, press enter.

Unless you have reason to want something other than the default format that it will pick (perhaps for compatibility with an old set-top media box), or need other options like turning off SSL verification for some sites (it does much more than youtube) that have this misconfigured, options for playlist, ..., ...

For the simplest and most common use case it is just copy+paste, but for others there are a lot of options. I prefer the CLI and manpage myself, but some are far more comfortable with a GUI, finding the options more discoverable that way.

(though having had a quick look at the project page it looks like this doesn't offer options beyond format selection, but for some users that is useful enough to warrant a GUI)

> I'm curious what is the reason for a GUI for such a simple utility?

From the screenshots alone some benefits are quite obvious. Namely the ability to handle multiple URLs at once, as also the Download-Manager with it's progress bar. I have a bunch of scripts myself for downloading videos, but interfaces for such things is not really a strength of the command line. I already thought about making some job-manager for myself because of those reasons. So I can totally understand people making a GUI and releasing it.

> The command line for this kind of tool seems like the perfect interface. Just copy a URL, paste it, press enter.

That's only if you have no other requirements. youtube-dl is a monster of parameters. You can setup any little crap and do many more things than just download a youtube-url. On the screenshot I see some config-buttons and some kind of profile? This quite matches with any mildly complex usecase for this tool. Having a GUI supporting you in setting up what other would do with scripts is beneficial, especially for those not breathing in shell-commands.

Unless the URL contains shell meta characters, such as "&"…

Modern shells have easy ways to deal with this, for example bracketed-paste-magic that ships with zsh.

The URL of this comment pastes like this, ready to be passed to commands:

    https://news.ycombinator.com/edit\?id\=29069520

Interesting, thanks. So apparently you're supposed to add

  autoload -Uz url-quote-magic
  zle -N self-insert url-quote-magic
  autoload -Uz bracketed-paste-magic
  zle -N bracketed-paste bracketed-paste-magic

to your zshrc to enable it.

It doesn't seem to escape $ (e.g. in <https://example.org/$PATH>), which doesn't inspire confidence…

Are there any equivalents for bash?

You can configure what gets quoted using url-metas:

    zstyle ':url-quote-magic:*' url-metas '*?[]^()~#{}=$'

Not sure about bash, I thought I remembered seeing something similar for it but a quick google doesn't turn up anything.

youtube-dl has 139 option flags some which require specifying an option along with the flag such as bitrate or file format.

I use this https://video-sauce.com it also let's you watch the video if you press the black logo at the bottom.

These sites always disappear but this one hasn't so far

Electron-based alternative: https://jely2002.github.io/youtube-dl-gui/

I built one in Flask, with background downloads and saved state/logs in SQLite. No JS, simple CSS styling with Bootstrap. Cool to see all of these. https://github.com/phubbard/ytdl-web

What would be really good, is some way to search a list of "artist - song title" to output a list of youtube video IDs.

You could search in your browser and copy the "/watch" URLs out of the results page if you wanted this. What would be the application, though? Do you want to download music videos?

Might be less complex to just create one line xPath query as a bookmarklet to get the ID's directly from the search results page.

youtube now throttling downloads right? or is there a workaround?

There are workarounds (detailed very nicely in dirkf’s pull request for youtube-dl):

https://github.com/ytdl-org/youtube-dl/pull/30184

Pasting the content here for convenience:

Since summer 2021, YouTube has started serving media URLs with a query parameter such as …&n=SXiXBH-xzrjeioPN&…. This now appears to be the default behaviour. Unless the value of this parameter is transformed according to an algorithm delivered in the site player JS, the download speed for the URL is throttled to ~50kB/s.

Solutions for this include:

• implementing a more complete JS interpreter, eg based on PR [jsinterp] Actual JS interpreter¹ #11272;

• using an external JS interpreter (PhantomJS, now unmaintained, is used by some extractors);

• spoofing the Android or iOS client to acquire unthrottled links, as successfully implemented in yt-dlp².

This PR takes a different approach derived from the successful solution used in VLC's youtube.lua (also implemented differently in pytube³). The approach relies on the fact that the challenge algorithm is served in a mini-language within the minified player JS and therefore the specific algorithm can be extracted and executed by interpreting the mini-language without actually running the JS itself. [In parallel with this PR, a separate implementation of this approach was added to yt-dlp⁴.]

The implementation of the mini-language interpreter is directly translated from VLC's n_descramble() Lua function⁵. The result sufficiently resembles the original that it should be straightforward to share changes between the two implementations.

――――――

¹ — https://github.com/ytdl-org/youtube-dl/pull/11272

² — https://github.com/yt-dlp/yt-dlp/commit/c888ffb95ab0ab4f4cd1...

³ — https://github.com/tfdahlin/pytube/blob/bb890af3b271a616bbe1...

⁴ — https://github.com/yt-dlp/yt-dlp/commit/404f611f1c4aa516fbc4...

⁵ — https://code.videolan.org/videolan/vlc/-/blob/4fb284e5af69aa...

It has been fixed in this fork: https://github.com/yt-dlp/yt-dlp

yt-dlp[0], a fork of youtube-dl has a workaround. youtube-dl is no longer developed.

[0]: https://github.com/yt-dlp/yt-dlp

the fork youtube dlp is not throttled, it's available through FireDM too

Any youtube-dl GUI for android? ( other than dvd)

NewPipe? https://newpipe.net

newpipe does not support downloading whole playlist

As someone who has been working with Python a lot up to this year, I am wondering has the state of GUI frameworks improved for Python in the recent months/years?

If I want to have, lets say, an application that looks (and works) like a native MacOS or Windows application, would I bet able to do that? All of the examples look really odd, with weird buttons and simply not feeling like native apps.

wxWidgets does use native controls so should feel like a native app. Sadly this is its only redeeming feature.

I'm curious way people hate on wxWidgets so much. As a cross platform GUI, it works, and has a better license for developers than QT, and when investigating QT it looked like it requires more than just a library, but QT specific tooling to build things.

> I'm curious way people hate on wxWidgets so much.

Because it just looks bad and outdated on most platforms.

Which would be a criticism of looking native, because that is all wxWidgets is doing. It's a wrapper for the underlying OS's native GUI.

Yeah but there is native and native. Both Windows and MacOS carry widgets and styles from so many releases, and there is some intelligence involved in picking up the "expected" one with the right style etc. WxWidgets seems to make the wrong choice very often, with the result that the apps look very dated. It's probably possible to make it do the right thing, but other toolkits just do that by default.

I've been thinking about this comment. It is super easy to enable which native gui one wants. However, I suspect the issue is one of cognitive overload: developing for the web is more complicated than developing native software for a single OS. These days, young developers learn web development first, and everything they learn is basically operating system independent. Simply the prospect of learning how to build software that is OS specific probably feels like a step backwards, and that negative cognitive association is enough to cause many/most young developers to groupthink themselves away from any native platform ambitions.

Poor quality (although I should qualify that by saying I haven't touched it for a long time).

Yes, it would possible to develop a GUI that looks native, but from my experience and those of others it's rather a hassle when you try to make something more complex.

PyQt and "QT for Python" both use the QT framework, which uses native widgets and supports Windows, MacOS, and KDE on Linux. It's kind of the gold-standard of desktop toolkits for Python.

This said, in the age of Electron, "things not looking native" does not seem to be a problem for most users.

And way less resource intensive than Electron.

The state of GUI frameworks full stop has not improved in the recent half-decade. As far as I can tell, we still have the same old problems; tkinter.ttk with the grid placement manager is still your best shot (and many languages, like Rust, don't even have something that good).

Reply on news.ycombinator.com