3 ms·

I use youtube-dl to download from Nico Nico Douga, which means having to restart the download every few minutes because the program doesn't send heartbeat reque

I use youtube-dl to download from Nico Nico Douga, which means having to restart the download every few minutes because the program doesn't send heartbeat requests. There's been a PR to fix this for a couple of years now [1], and a more recent updated PR to add encrypted video support [2], both of which are still open. Meanwhile, the corresponding PR on youtube-dlc [3] is actively being looked at. [1] https://github.com/ytdl-org/youtube-dl/pull/18230 https://github.com/ytdl-org/youtube-dl/pull/18230 [2] https://github.com/ytdl-org/youtube-dl/pull/23824 https://github.com/ytdl-org/youtube-dl/pull/23824 [3] https://github.com/blackjack4494/youtube-dlc/pull/55 https://github.com/blackjack4494/youtube-dlc/pull/55

raziel2p 6y ago
It makes sense that it's easier to give <100 PRs attention than 25k+. If the DLC project grows, you can't know if the same won't happen again. 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.
- masklinn 6y ago
  > It makes sense that it's easier to give <100 PRs attention than 25k+. 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.
  - hombre_fatal 6y ago
    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) fork.
    - yorwba 6y ago
      > It's not like the forker inherited all the open issues/PRs, they just dropped them all. 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. https://github.com/blackjack4494/youtube-dlc/commits/master https://github.com/blackjack4494/youtube-dlc/commits/master
    - theidel 6y ago
      Actually I merged quite some PRs that were open or even closed. However I tested and reviewed all I can but those geoblocked ones. But most of these were verified already or I could use some simple self hosted vpn. But do note that my reviews are not really in line with the strict coding conventions originating from the main project. As long as it works and isn't totally gibberish it will be approved by me. I rather want functionality and somewhat stability quite fast. Although totally agree reviewing can be such a pain..

raziel2p 6y ago

It makes sense that it's easier to give <100 PRs attention than 25k+. If the DLC project grows, you can't know if the same won't happen again. 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.

masklinn 6y ago
> It makes sense that it's easier to give <100 PRs attention than 25k+. 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.
- hombre_fatal 6y ago
  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) fork.
  - yorwba 6y ago
    > It's not like the forker inherited all the open issues/PRs, they just dropped them all. 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. https://github.com/blackjack4494/youtube-dlc/commits/master https://github.com/blackjack4494/youtube-dlc/commits/master
  - theidel 6y ago
    Actually I merged quite some PRs that were open or even closed. However I tested and reviewed all I can but those geoblocked ones. But most of these were verified already or I could use some simple self hosted vpn. But do note that my reviews are not really in line with the strict coding conventions originating from the main project. As long as it works and isn't totally gibberish it will be approved by me. I rather want functionality and somewhat stability quite fast. Although totally agree reviewing can be such a pain..