[HN Gopher] A cross-platform GUI for YouTube-dl
___________________________________________________________________
A cross-platform GUI for YouTube-dl
Author : ducktective
Score : 366 points
Date : 2021-09-10 07:11 UTC (15 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jccalhoun wrote:
| 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
| filmgirlcw wrote:
| Yeah I think it is but this is a great Windows option, thanks
| for the share!
| iKlsR wrote:
| 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
| qwerty456127 wrote:
| 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.
| db48x wrote:
| I just use a shell script.
| IggleSniggle wrote:
| 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!
| iKlsR wrote:
| 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.
| q-rews wrote:
| 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.
| qwerty456127 wrote:
| 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.
| FerritMans wrote:
| This is exactly what I have been looking for, any chance you
| could make this public?
| iKlsR wrote:
| Unfortunately no immediate plans to do so. It was a quick
| weekend project to scratch an itch.
| m348e912 wrote:
| 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.
| iKlsR wrote:
| 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. :)
| deaddodo wrote:
| 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.
| bityard wrote:
| 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.
| notsureaboutpg wrote:
| Yeah, I do this with the channels I like and save them
| directly to my DLNA server at home using a systemd timer
| (i.e. cron job).
|
| I patreon the channels, and an added bonus is no ads. I
| don't care too much about deleted videos, and when YouTube
| Premium Lite rolls out to the USA I'll pay for that (I
| don't listen to music so YouTube Music features are wasted
| money for me)
| Karrot_Kream wrote:
| You might enjoy youtube-local:
| https://github.com/user234683/youtube-local
| CapriciousCptl wrote:
| 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.
| iKlsR wrote:
| 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...
| yboris wrote:
| 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
| iKlsR wrote:
| 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.
| bluedays wrote:
| I was playing around with something similar a while back.
|
| https://github.com/bluedaze/ytADL
| okasaki wrote:
| I made a very simple youtube-dl front-end that runs locally in a
| browser (flask, no javascript):
|
| https://github.com/dvolk/lo2#readme
| qwerty456127 wrote:
| 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.
| capevace wrote:
| 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
| yutijke wrote:
| 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.
| pjmlp wrote:
| We need to educate what browsers are capable of,
|
| https://whatwebcando.today/
|
| https://whatwebcando.today/files.html
| guilamu wrote:
| Have you tried freetube? (I'm unsure if it's electron though)
| areille wrote:
| Freetube uses Electron (from project README :
| https://github.com/FreeTubeApp/FreeTube)
| aero-glide2 wrote:
| 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.
| zapzupnz wrote:
| 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.
| leokennis wrote:
| 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...
| kasabali wrote:
| Youtube throttles download speeds.
| inshadows wrote:
| > package.json
|
| Ctrl-W, bye
| BiteCode_dev wrote:
| 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.
| AndyPa32 wrote:
| The version my Linux distro supports is always helplessly
| outdated. But with conda I always get the latest version of
| youtube-dl.
| Trex_Egg wrote:
| Thanks bro
| baobabKoodaa wrote:
| 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
| filmgirlcw wrote:
| 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.
| flixic wrote:
| 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.
| smashah wrote:
| This would require some sort of open-api type spec but for
| CLIs. I like this idea. Good luck to anyone taking it up.
| ape4 wrote:
| Everything doesn't have to be JSON ;)
| cabalamat wrote:
| 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
| bavell wrote:
| 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.
| cabalamat wrote:
| > 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.
| bityard wrote:
| 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.
| cabalamat wrote:
| > JSON is verbose and writing anything decently
| complicated with it sounds like torture.
|
| Except in comparison with XML :-)
| lbqjfw wrote:
| For native Mac apps, there is Platypus that does something
| similar: https://sveinbjorn.org/platypus
| colejohnson66 wrote:
| XML based UIs already exist with GtkBuilder and QtQuick(?).
| Although, your idea is more complex than that.
| jonny_eh wrote:
| HTML is a pretty good XML-like UI builder.
| ducktective wrote:
| 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
| flixic wrote:
| 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" }
| [deleted]
| platz wrote:
| i was surprised how close this gets
| https://sanana.kiev.ua/index.php/yad
| cabalamat wrote:
| 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.
| hungryforcodes wrote:
| 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.
| cabalamat wrote:
| > 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.
| drran wrote:
| 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.
| jonny_eh wrote:
| 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.
| _jal wrote:
| The best clothes are hand-tailored specifically to fit your
| body.
|
| And yet, most people wear mass-produced clothes.
| NegativeLatency wrote:
| Well yes but to continue the metaphor almost nobody wears
| barrels
| HWR_14 wrote:
| Mass produced clothes are significantly cheaper than
| barrels. Several orders of magnitude.
| goldenkey wrote:
| 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
| flixic wrote:
| 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.
| discordance wrote:
| 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.
| flixic wrote:
| 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.
| MR4D wrote:
| So like a modern day VB3 but built on Electron. Would be nice
| to have!
| notRobot wrote:
| preferably _not_ electron :)
| MR4D wrote:
| 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.
| HWR_14 wrote:
| > 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?
| genewitch wrote:
| Minecraft. q.e.d.
| zorr wrote:
| Not JSON, but related: Kaptain.
|
| https://github.com/mviereck/kaptain
| flixic wrote:
| 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.
| slightwinder wrote:
| 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.
| flixic wrote:
| 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 (:
| jonny_eh wrote:
| > HTML is too complex
|
| The suggestion was a simplified subset of HTML.
| jhgb wrote:
| Sounds a bit like Sciter, then.
| slightwinder wrote:
| 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.
| jjnoakes wrote:
| 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.
| user234683 wrote:
| 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.
| esel2k wrote:
| 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?
| chetangoti wrote:
| 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
| davzie wrote:
| 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.
| lostgame wrote:
| I think there's a massive legal risk from monetizing something
| that exists to download mostly copyrighted content.
| genewitch wrote:
| 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.
| ducktective wrote:
| How did you reach that conclusion from your premise?
| rgoulter wrote:
| 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.
| colejohnson66 wrote:
| 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.
| TheNewAndy wrote:
| I assumed that most of the web based ones were using youtube-
| dl behind the scenes.
| ducktective wrote:
| _I 'm not affiliated with this project in any way. I just posted
| for publicity_
| brabel wrote:
| In case you're wondering: yes, it uses Electron. Because you
| definitely need yet another browser just to watch youtube videos.
| qwerty456127 wrote:
| 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).
| pjmlp wrote:
| If only the Web had a file API.
|
| https://developer.mozilla.org/en-US/docs/Web/API/FileSystem
| LordRishav wrote:
| 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.
| poisonborz wrote:
| 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.
| poisonborz wrote:
| 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?
| pluc wrote:
| It's a CLI app, it doesn't need "an app" for it.
| tclancy wrote:
| 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.
| fsloth wrote:
| 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.
| dotancohen wrote:
| $ 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?
| fsloth wrote:
| 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.
| dotancohen wrote:
| 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.
| poisonborz wrote:
| 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.
| lpcvoid wrote:
| 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.
| wing-_-nuts wrote:
| 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?
| imbnwa wrote:
| > youtube-dl is a 10 year old project. Where are all the
| great qt gui-s for it?
| poisonborz wrote:
| 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.
| lpcvoid wrote:
| 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.
| poisonborz wrote:
| 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".
| genewitch wrote:
| The only good phone is a landline and it should be made
| of bakelite.
| crazygringo wrote:
| > _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.
| lpcvoid wrote:
| Constantly providing an "easy way out" for problems in
| form of technically inferior solutions is not a good path
| to tread on.
| filmgirlcw wrote:
| So no one should ever do anything unless it is
| technically perfect?
|
| That's an even worse path to tread on.
| filmgirlcw wrote:
| 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.
| ducktective wrote:
| > 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
| illegalmemory wrote:
| 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.
| [deleted]
| sen wrote:
| 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/
| PaulKeeble wrote:
| 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/
| dEnigma wrote:
| 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).
| sen wrote:
| 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.
| sundarurfriend wrote:
| 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.
| KaoruAoiShiho wrote:
| Is this using the original yt-dl or the fork with more features?
| https://github.com/yt-dlp/yt-dlp
| filmgirlcw wrote:
| 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.
| Kopty wrote:
| Thank you for this! It is super valuable.
| hardwaresofton wrote:
| Another self-hostable option that runs as a server (and you
| access with a browser):
|
| https://github.com/alexta69/metube
| bshep wrote:
| 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?
| hardwaresofton wrote:
| 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/
| sylphaenos wrote:
| Check my other reply, Tzahi12345/YoutubeDL-Material supports
| this. No affiliation, just started using it myself.
| sylphaenos wrote:
| Similar project, but allows watching in the browser &
| downloading to your client machine:
|
| https://github.com/Tzahi12345/YoutubeDL-Material
| john_minsk wrote:
| That's perfect. It is funny how this is better than youtube in so
| many ways. If only it could be taken mainstream.
| mxuribe wrote:
| > ...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. :-)
| severine wrote:
| 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!
| qwerty456127 wrote:
| Which seems particularly inappropriate given the GUI is web-
| based.
| yboris wrote:
| 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
| zapzupnz wrote:
| The words "cross-platform" caught my eye, but I don't see any
| screenshots of the program on macOS or Linux.
| opencl wrote:
| It's Electron, the Mac and Linux versions will look exactly the
| same.
| zapzupnz wrote:
| That's not always a given. It's possible for Electron apps to
| have per platform styling.
| OJFord wrote:
| It's using Electron, is there any reason to show three
| ~identical screenshots?
| zapzupnz wrote:
| 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.
| OJFord wrote:
| 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'.
| zapzupnz wrote:
| > 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.
| MR4D wrote:
| WOW - 100MB download for Mac!
|
| However, once I installed it, it ran really well. Interface is
| smooth and nice.
| stjohnswarts wrote:
| 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.
| jokoon wrote:
| Nice!
|
| Are you planning to support all options?
| freewizard wrote:
| 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?
| johnchristopher wrote:
| Really, really nice. Preview displays rating, duration,
| thumbnail, etc. for playlist and you can change individual
| setting for items of a playlist.
| nikkinana wrote:
| Oh what a waste of effort boys.
___________________________________________________________________
(page generated 2021-09-10 23:02 UTC)