YT: Batch Archive - Only 5 retries of 10 when fragment unavailable and set to abort on both (error and fragment)

[altimumdelta]

Checklist

• I'm reporting a broken site support issue
• I've verified that I'm running youtube-dl version 2019.04.30
• I've checked that all provided URLs are alive and playable in a browser
• I've checked that all URLs and arguments with special characters are properly quoted or escaped
• I've searched the bugtracker for similar bug reports including closed ones
• I've read bugs section in FAQ

Verbose log

[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v']
[debug] Encodings: locale cp1250, fs mbcs, out cp852, pref cp1250
[debug] youtube-dl version 2019.04.30
[debug] Python version 3.4.4 (CPython) - Windows-10-10.0.14393
[debug] exe versions: ffmpeg N-93276-g3b23eb283a, ffprobe N-93276-g3b23eb283a

Verbose not possible. Cannot recreate the problem at this time.

[download]  22.7% of 114.18MiB at  1.31MiB/s ETA 01:07         [download] Got server HTTP error: The read operation timed out. Retrying (attempt 5 of 10)...
ERROR: unable to download video data: The read operation timed out

Description

The program only tried 5 times out of the default 10 when a fragment is unavailable. It is not conclusive whether the options --abort-on-error and/or --abort-on-unavailable-fragment have anything to do with this but the problem cannot be recreated at this time (the download succeeds without issue at the time of writing this)

[vxbinaca]

Manually set frag retries higher. RTFM.

[altimumdelta]

Manually set frag retries higher. RTFM.

Sure that's just the workaround, has nothing to do with the fact that it's not functioning as it was meant to.
This is a bug report, not a question regarding possible workarounds. If the default is 10, it should be 10 unless told otherwise.

[vxbinaca]

You didn't include the command. It's not a workaround it's a safety feature for bad internet connections or wonky days at YouTube.

[altimumdelta]

You didn't include the command. It's not a workaround it's a safety feature for bad internet connections or wonky days at YouTube.

Well in this case it also works as a workaround for the broken default behavior, apart from it's main design function, which doesn't matter in this case. Still, what does any of this have to do with the bug?

I did forget to include the command. The command would have only double-cleared up that I wasn't using any override switches, if it wasn't presumed from the fact that I mentioned "default 10" in the description.

The default behavior is broken and it can't be my fault. It's just simple as that. I'm not sure since when it is expected that workarounds have to be relied upon for broken default behavior, whether or not the user has read the manual.

Unless, the Manual expressly says that the default behavior is (left) broken, so it would keep stopping after 5 retries of the intended 10, unless an override switch is used to manually set it above 5, only in that case would it be the user's fault.