81–90 of 109 posts
A GUI-based alternative is JDownloader
It takes a second to get how it works, but you can update youtube-dl from within the gui and it handles queues and all sorts of things really well.
The repository provides no reasons that brought the need for a fork. Can someone provide additional information?
This is something I was going to address but wasn't my main focus in the beginning. But I made another write-up on reddit https://www.reddit.com/r/DataHoarder/comments/ir8ic6/youtube... A tiny conversation about this here as well https://github.com/blackjack4494/youtube-dlc/issues/56#issue...
Mention. it. in. the. code.
Adding a comment here and on Reddit is useless if nobody else sees it.
Explaining why a fork exists should be the first thing people read, especially how “everything is a fork” on GitHub.
Earlier quoted context omitted.
It makes sense that it's easier to give Not saying forks should never happen - streamlink and KeepassXC are examples of great forks off the top of my mind - but you can't judge just on anecdotal stale PRs.
> It makes sense that it's easier to give ydl has 700 open PRs, not 25k+. ydl hasn't had 25k+ PRs in its lifetime either, it's had 4k: GH issues and PRs are the same object, so the sequence is shared.
It's not like the forker inherited all the open issues/PRs, they just dropped them all.
Getting popular and having the masses leave a bunch of issues/PRs is hard. Reviewing code is hard and takes more expertise than writing it. A lot harder than reviewing your own PRs on a motivated (for now) fork.
Earlier quoted context omitted.
I maintain several open source projects. Sometimes PR are not merged for years. I'm not payed for this, I'm not even thanked for this most of the time, so I'm certainly not going to set any deadline. But forking might be a solution, if you can give the necessary horse power for the long run. Most can't.
It’s odd to me how nontechnical people have migrated to GitHub to make bug reports on software they use. The other day, I was trying to use a Python library to scrape some stuff. It kept breaking. I looked on the issues page and there were many, essentially useless bug reports asking them to fix the issue. I opened up the script and changed about 7 lines and it worked fine.
At times I imagine there could be some kind of "I know how to report bugs"-certification that people could somehow earn. Projects could then use this as a barrier to prevent getting too many useless issue reports.
The problem really goes both ways - as a software dev I'm disincentivized to report detailed bugs to projects, because there's a high risk it will get drowned out in the noise.
Some projects have quite specific templates for reporting issues. This helps a bit, but you still need someone to go in and remove issues that don't match the template, and few people want to volunteer for that work.
Isn’t youtube-dl already updated all the time to keep up with scraping changes? I don’t understand why this would claim to be more maintained?
Seems to have been originally spawned from this discussion: "Youtube-dl is dying?" https://github.com/ytdl-org/youtube-dl/issues/26462 citing many PRs are not getting merged. Anecdote: youtube-dl still works for all the sites I'm using it for.
https://github.com/ytdl-org/youtube-dl/issues/23860
He closed it without even addressing the issue of him closing the related issues that I explicitly brought up. There are scores of issues describing the same issue, but all of them are closed, and more of them are still being submitted. This has been going on since April of last year.
It's making me realize that sometimes a fork really is the only way to get around the problem that you're not in control of the project and there are bugs that many people need to be fixed.
Isn’t youtube-dl already updated all the time to keep up with scraping changes? I don’t understand why this would claim to be more maintained?
Getting a fix merged to youtube-dl is quite an endeavour. No criticism to the fantastic maintainers - I encourage them to run their excellent project however suits them best - but I’m not going to try again in future.
Earlier quoted context omitted.
> It makes sense that it's easier to give ydl has 700 open PRs, not 25k+. ydl hasn't had 25k+ PRs in its lifetime either, it's had 4k: GH issues and PRs are the same object, so the sequence is shared.
Doesn't change the point. All of the fork's 55 PRs except 2 and most of the issues were made by the forker himself as well. It's not like the forker inherited all the open issues/PRs, they just dropped them all. Getting popular and having the masses leave a bunch of issues/PRs is hard. Reviewing code is hard and takes more expertise than writing it. A lot harder than reviewing your own PRs on a motivated (for now) fo…
That's wrong, most of the recent commits in the fork are merging branches from a lot of other repos. GitHub doesn't have a mechanism for inheriting a project's pull requests when you fork, but that doesn't mean they're automatically "dropped", since you can still merge the corresponding branch.
Earlier quoted context omitted.
Getting a fix merged to youtube-dl is quite an endeavour. No criticism to the fantastic maintainers - I encourage them to run their excellent project however suits them best - but I’m not going to try again in future.
Are PR visible to other users where they could make the same change to their local version even if the maintainer does not accept the PR in a timely manner? I know it is no where near the same, but just wondering.
Earlier quoted context omitted.
Seems to have been originally spawned from this discussion: "Youtube-dl is dying?" https://github.com/ytdl-org/youtube-dl/issues/26462 citing many PRs are not getting merged. Anecdote: youtube-dl still works for all the sites I'm using it for.
There is an issue preventing the download of Watch Later playlists that has been open for over a year. The core maintainer, dstftw, closes all reports related to it with "duplicate" while never giving a reason or the original issue. See this issue I filed for an example. https://github.com/ytdl-org/youtube-dl/issues/23860 He closed it without even addressing the issue of him closing the related issues that I explicit…
Earlier quoted context omitted.
It’s odd to me how nontechnical people have migrated to GitHub to make bug reports on software they use. The other day, I was trying to use a Python library to scrape some stuff. It kept breaking. I looked on the issues page and there were many, essentially useless bug reports asking them to fix the issue. I opened up the script and changed about 7 lines and it worked fine.
There are two factors at play here I think. The first is that Github has become quite popular. The second is that Github has worked a lot on usability - it's now very easy for users who are not very technical to create an account and report issues. At times I imagine there could be some kind of "I know how to report bugs"-certification that people could somehow earn. Projects could then use this as a barrier to preve…
I mostly use GitHub to find off the shelf solutions to whatever problem I’m having or to avoid doing the work myself. If I run into any problems I have with something from there, I either try and fix it by tweaking the repository, using another, or just building the thing myself. I think the last time I reported an issue on an external repository was because of something I was made to use at work.