Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Feature request: Please provide anti-freezup option when using native downloader or --hls-prefer-native option #18306
Labels
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is to address a problem that seems to occur on many services but only apparently with certain providers. In cases where the "native" downloader is used (by adding the --hls-prefer-native option, for example), I would like an option that would do the following:
Detect if the download has "frozen", that is data either stops coming in completely or comes at such a slow rate that the percentage counter completely stops counting.
If so then delete any partially downloaded fragments (something like
rm *.mp4.part-Frag*.part) and effectively restart the program so that it tries to pick up where it left off, but without the partial fragment. This is very important since in such situations the partially downloaded fragment almost always contains bad data.In my testing if you Control-C out when this happens, delete the partial fragment if any, and then restart the program it will successfully pick up where it was interrupted. But in some cases you may have to do that dozens of times to get a final good recording. It is a real pain to do that which is why I was hoping maybe that particular functionality can be automated. This problem started around the time the network neutrality was killed, so my suspicion is that ISP's are using their new-found freedom to muck with random fragments as they are transmitted
If you do implement this it should probably let you specify the number of seconds to wait before the download is considered frozen, although from what I have seen 10 seconds would be a good value. If the percentage counter hasn't incremented in ten seconds it never will, in my experience.
Note that when this happens it always happens at a different spot in the recordings, and if you are on a different ISP you may well never see the problem at all.
None of the existing options seem to deal with this (I tried several). I'm really not sure if the data stream dies completely, or just gets so incredibly slow that it looks completely frozen.