--no-continue behavior is not documented correctly

[undaunt]

Checklist

• I'm asking a question
• I've looked through the README and FAQ for similar questions
• I've searched the bugtracker for similar questions including closed ones

Question

I'm wondering what the intended behavior of --no-continue is, whether its the entire fill is supposed to be restarted from 0% upon interrupt and resume, or only the in-progress fragment? Earlier today I interrupted a file at 47% and it resumed at 47% on next run.

See this issue, open on parent without any follow up - ytdl-org/youtube-dl#21467 - not sure if you'd have any insight or if things are working as expected. Thanks!

[pukkandan]

I actually don't know what it's supposed to do. Let me see if I can figure it out from the source code

[pukkandan]

After some investigation of the source-code, I can confirm that @SebiderSushi 's analysis is correct. Only the current file is re-download. Since each fragment is first downloaded to a seperate file, only the current fragment is redownloaded for fragmented videos. I will change the readme to reflect this.

[pukkandan]

I'm not good at writing documentation. What do you think of:

--continue       Resume partially downloaded fragments/files (default)
--no-continue    Restart download of partially downloaded fragments/files

[undaunt]

maybe

-c, --continue   Resume partially downloaded files/fragments (default)
--no-continue    Restart download of partially downloaded files/fragments after last completed fragment

That way we keep files listed first, similar to existing doc, and we make very clear it only restarts after last fragment finished, no unclear language around partially downloaded file restarting from 0.

OR, to keep it shorter:

-c, --continue   Resume partially downloaded files (default)
--no-continue    Restart download of partially downloaded files after last completed fragment

That way fragments are only mentioned once, when relevant. Most similar to existing, just replacing 'from beginning' with 'after last completed fragment'

[pukkandan]

Restart download of partially downloaded files after last completed fragment

This is still ambiguous as to what happens if the file is not fragmented

I dont think a small description can sufficiently explain the feature. I might go with a longer description like:

Do not resume download of partially downloaded fragments. If the file is not fragmented, the download is restarted from the beginning

[undaunt]

That's a fair point, though does it ever actually restart fully from 0? I haven't seen that behavior, only the percentage of where it was prior as long as there is a .part file.

[pukkandan]

Yes it does. Try downloading -f 22. It should always start from scratch

[undaunt]

Ah good point, I just don't usually grab that format.

Maybe:

-c, --continue   Resume partially downloaded files/fragments (default)
--no-continue    Restart partial file downloads from the beginning. If the format supports fragments, resume from the last completed fragment.