Has anyone else noticed slow loading fragments cause youtube-dl to halt completely?

[tv21]

Please follow the guide below

• You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
• Put an x into all the boxes [ ] relevant to your issue (like this: [x])
• Use the Preview tab to see what your issue will actually look like

---

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2018.10.05. If it's not, read this FAQ entry and update. Issues with outdated version will be rejected.

• I've verified and I assure that I'm running youtube-dl 2018.10.05

Before submitting an issue make sure you have:

• At least skimmed through the README, most notably the FAQ and BUGS sections
• Searched the bugtracker for similar issues including closed ones
• Checked that provided video/audio/playlist URLs (if any) are alive and playable in a browser

What is the purpose of your issue?

• Bug report (encountered problems with youtube-dl)
• Site support request (request for adding support for a new site)
• Feature request (request for a new functionality)
• Question
• Other

---

Description of your issue, suggested solution and other information

I just wanted to ask if anyone else has noticed an issue where you start getting a video using youtube-dl and (if you don't use the --force-generic-extractor option) it hands off to ffmpeg, and ffmpeg starts getting fragments, printing a line of information for each fragment it gets, but then at some random point it hits a fragment that seems to trickle in EXTREMELY slowly (at a rate that would make a dial-up modem seem speedy) and then finally dies. This seems to primarily happen on services when the video is served by (something).akamaihd.net but is not limited to any one service.

What I wish would happen is when a fragment starts coming in so slowly, if would just bail out after a few seconds and retry. I have also tried using the --force-generic-extractor option and while that will also start the file downloading, at some the same problem occurs. Either way, the rate limiting option (such as -r 50K) doesn't seem to slow the download speed at all.

If you wait and keep retrying every few hours eventually you may be able to actually get the entire video but it's very much an issue of luck. Even one slow/stalled fragment, no matter where it occurs in the video, makes the whole download unusable.

It would be very helpful if there were a way to restart the download from the last GOOD fragment downloaded (not the one that caused the stall) but I can't find any way to do that. I don't know if I am just missing an option here or what. This isn't covered in your FAQ but if there is a solution, it probably should be. Anyway, I'd just like to know if anyone else has experienced this and if there is an option or combination of options that will get around this problem.

[remitamine]

It would be very helpful if there were a way to restart the download from the last GOOD fragment downloaded (not the one that caused the stall) but I can't find any way to do that. I don't know if I am just missing an option here or what.
I'd just like to know if anyone else has experienced this and if there is an option or combination of options that will get around this problem.

--hls-prefer-native              Use the native HLS downloader instead of
                                 ffmpeg

[tv21]

--hls-prefer-native              Use the native HLS downloader instead of
                                 ffmpeg

This does work but at each point where the file is restarted there is a notable glitch in the video (and sometimes the audio is well). My suspicion is that this is because it's trying to keep and append to the last partial fragment received, instead of throwing it away and restarting after the last fully received fragment. Is there an option to discard the partial fragment, or instruct youtube-dl not to try to append to a partial fragment?