Repository: yt-dlp
Issue: Upon error, delay & restart the download a user-defined number X of times with user-defined Y seconds delay between each time.
Labels: enhancement,triage

### DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

- [X] I understand that I will be **blocked** if I *intentionally* remove or skip any mandatory\* field

### Checklist

- [X] I'm requesting a feature unrelated to a specific site
- [X] I've looked through the [README](https://github.com/yt-dlp/yt-dlp#readme)
- [X] I've verified that I have **updated yt-dlp to nightly or master** ([update instructions](https://github.com/yt-dlp/yt-dlp#update-channels))
- [X] I've searched [known issues](https://github.com/yt-dlp/yt-dlp/issues/3766) and the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar issues **including closed ones**. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)

### Provide a description that is worded well enough to be understood

My suggestion is prompted by but is also not limited to the current issue:
ERROR: [youtube] ... Sign in to confirm you're not a bot. This helps protect our community.
- I believe this solution will solve this specific youtube error for many - especially when implimented proactively before the issue develops for a current IP address.
- Even so, this feature would also be useful as a general feature, not simply for youtube and not simply in response to that single error.

Allow me to provide the initial backstory.  Firstly as an important side note, my IP is not currently or generally blocked by youtube; but when too many requests are made in too short a period of time, youtube gives me this error.  However if I wait long enough before attempting to request more information, the error goes away.  So, I suppose that I am temporaily blocked at such times, but the block is very brief, a matter of minutes.  Yet if I were to continue to send requests despite the temporary block, I expect that the block would be extended or even become permanent.

In my case, I have a batch file which pulls multiple instances of yt-dlp sequentially; and using yt-dlp commands, I have set delays between each download (and each subtitle download) so as to attempt to avoid an IP block.  Even so (and especially when pulling page requests for users with many videos), I occasionally get this error.  Since there then is no actual download taking place, there is then also (& despite my set delays) no delay before the next request - resulting in many requests in rapid succession.  I fear that this puts me at risk of a more substantial block.

Thankfully often times, I leave the command window visible while I am performing other tasks on my computer.  So, I often enough see the error when it is occurring.  Upon seeing it, I then pause the script by literally using the "Pause" button on my keyboard.  After a while, I then press any key to unpause the script; and now, it runs without the error.  I essentially waitout the temporary ban.

So, I am requesting 1 feature with 2 aspects.  Repeating my feature request title, I would like to have the following:
Upon error, delay & restart the download a user-defined number X of times with user-defined Y seconds delay between each time.
To flesh that out a bit more, I want yt-dlp to take an action upon seeing such an error.  For that action, I want it to pause a user-defined number of seconds Y before attempting the download again.  After retrying the download a user-defined number of times X, I want it to then skip the file.

Finally, I could easily see a use-case scenario where the script pauses indefinitely after the set number of attempts.  At such a point, a user input would be requested as to whether to then skip or retry.  This would be, for example, useful if an error was actually due to a loss of internet connection or if a site temporarily went down.  Thusly, it would be able to be easily restarted manually by the user at the same point and after any connection issues were resolved.  While not needed for my use-case scenario, this is merely suggested here as a proactive bit of coding in the same section.

So again, there are 2 reasons for my feature request:
(1) It will help prevent users from being blocked on sites such as youtube.
(2) It will allow temporarily blocked downloading to subsequently continue from the same point (not restarting an entire batch sequence) automatically or with manual users.


Recommended syntax:
--error-retries RETRIES
   Number of retries for download upon an error
   (default is 3), or "infinite" (DASH, hlsnative and ISM)
--error-sleep-interval SECONDS
   Number of seconds to sleep
   before each retry upon an error
   when used alone or a lower bound of a range
   for randomized sleep before each retry
   (minimum possible number of seconds to sleep)
   when used along with --error-max-sleep-interval
--error-max-sleep-interval SECONDS
   Upper bound of a range for randomized sleep
   before each retry upon an error
   (maximum possible number of seconds to sleep).
   Must only be used along with --error-sleep-interval
--pause-on-error
   Pause downloading of further videos
   (in the playlist or the command line)
   if an error occurs.
   This happens only after set number of attempted retries.
   see also: --error-retries
                  --abort-on-error


Syntax to be considered and/or adjusted:
--abort-on-error
   Abort downloading of further videos
   (in the playlist or the command line)
   if an error occurs.
Lines to add to description:
   This happens only after set number of attempted retries.
   see also: --error-retries
                  --pause-on-error
Reasoning: Currently, --abort-on-error does not consider any --error-retries but simply & immediately aborts.  This should then consider retries first, if any are defined.  Otherwise, this would behave as usual.
Naturally, --abort-on-error and --pause-on-error would be mutually exclusive.


Coincidental side notes:
Currently, there is an error on:
https://github.com/ytdl-org/youtube-dl?tab=readme-ov-file#options
The desciption for
--max-sleep-interval
refers to
--min-sleep-interval
which does not actually exist.
Properly, this simply should refer to
--sleep-interval

### Provide verbose output that clearly demonstrates the problem

- [ ] Run **your** yt-dlp command with **-vU** flag added (`yt-dlp -vU <your command line>`)
- [ ] If using API, add `'verbose': True` to `YoutubeDL` params instead
- [ ] Copy the WHOLE output (starting with `[debug] Command-line config`) and insert it below

### Complete Verbose Output

_No response_