--no-abort-on-error and --ignore-errors don't work as documented #4914
Comments
|
Here is thumbnail missing, I get a warning (not a crash like the missing subtitle above):
|
|
And here I switch the order of (Some redundant stuff snipped not to exceed github comment length limits) |
You're looking at the Youtube-dl readme. In the yt-dlp readme it's documented as: (I'll read the rest of your message later) |
Missing thumbnail is just a warning because that is "expected" to happen due to the way we extract thumbnails. This is not true for subtitles. This is the same reason thumbnails have fallbacks while subtitles doesn't
Already documented as gamer191 said. Do have suggestion for improving it?
The order matters for any two options that control similar things. Eg: I assumed this much would be obvious from the existing documentation. After reading yt-dlp's docs, could you explain what else you would expect to happen when giving
This is not possible due to various reasons
Does that address all your points? |
My mistake, I was comparing both youtube-dl and yt-dlp and mispasted. However, there rest of my issue holds (based upon the fact I was reading yt-dlp code for the most part) |
Yeah, but youtube claims it has automatic subtitles in the following languages: but doesn't have subtitles for und-en (language: "Undetermined"). I can't imagine someone calling with What do you think the behavior should be then? Or maybe there should be an extra flag to ignore missing transcriptions? At least then we don't break compatibility with youtube-dl upstream by adding functionality.
My mistake. I was mainly consulting the code to understand this, and then copy-and-pasted from youtube-dl when I was filing this issue. I've been staring at this for a while, so I was a bit fatigued.
Yes, agreed that there must be cases where the order matters. But still, when possible, it is nicer when flags are commutative and the order is not important. That's not always possible, but it definitely makes things simpler and nicer when it is possible.
I mean, when I read "--ignore-errors: Ignore download and postprocessing errors. The download will be considered successful even if the postprocessing fails", I assume that means that if one weird autotranscription fails like I guess the confusion for me is that I think of getting the video, and you think of getting the video AND all the subtitles and other artifacts (but not the thumbnail for reasons I don't really understand?). "--no-abort-on-error Continue with next video on download errors; e.g. to skip unavailable videos in a playlist (default)" to me means try to get the entire playlist of videos, even if the previous video could not be retrieved. I guess I'm still confused. It's like the JSON and the metadata and the thumbnail are soft warnings but the subtitles are hard errors? Or something like that? That's what I don't really grok.
Yeah, I understand the desire for that. Perhaps a new flag that is more obvious and deprecates the confusing old flags would be good?
I mean there are two schools of thought on this, it's really kind of a question of preference here. My argument is that if In general, I just think: If you have two overlapping flags, but you can treat them as two if-clauses where the order doesn't matter; that's preferable and easier to understand than compacting them into a ternary case with nested ifs where the behavior changes depending upon the order of the flags.
I guess the main thing I'm really confused about is what is consider a soft warning and what is considered a hard error in terms of "download this video and associated artifacts". And I still would prefer a new flag that is really self-explanatory and doesn't require understanding intricacies like "und-en subtitles are crucial but thumbnails are not" and instead is like: "the video file itself is crucial, everything else is just icing on the cake" |
This sounds like an extractor bug. I will look into it Btw, not really related to this; if your intention of downloading all subs is archiving, I would recommend using |
In general, everything is a hard error unless I think that a lot of the confusion came from the word "postprocessing" in the option description. This also actually includes pre-processing, including artifact downloads.
Ah, now I finally understand your actual requirement! What you want is a way to set issues in video download as hard errors, and everything else as a soft error, correct? I will think about if/how this can be implemented and get back to you. |
pukkandan
added
enhancement
Thank you for the tip! Yeah, I'm trying to upstream yt-dlp into ArchiveBox to replace youtube-dl, so archival is the goal. But isn't |
Yeah :) Basically if you understand my use case, trying to pull yt-dlp into ArchiveBox to replace youtube-dl, and be one of the different ways that a URL is archived, that's my mental model I'm coming from |
DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE
Checklist
Provide a description that is worded well enough to be understood
Summary
The order of
--ignore-errorsand--no-abort-on-erroris crucially important, but this is a gotcha based upon the documentation.Weirdly,
--abort-on-error==--no-ignore-errors, but--ignore-errors!=--no-abort-on-error.--no-abort-on-erroris undocumented in the README.This is important if one subtitle is missing, it can cause an abort. As opposed to if the thumbnail is missing, and then you just get a warning.
Details
The following options are poorly documented, inconsistent, and can lead to footguns.
From the README:
However, from the code:
So, basically the behavior is:
--ignore-errors=>ignoreerrors = True--no-ignore-errors=>ignoreerrors = False--abort-on-error=>ignoreerrors = False--no-abort-on-error=>ignoreerrors = only_downloadThis is such a footgun because:
--abort-on-errorand--no-abort-on-erroropposites?and MOST CRUCIALLY,
--no-abort-on-errorwould lead you to believe that if everything downloads correctly except a single subtitle file, that you should be fine. But instead the whole process aborts.This has confused other people, but is not the same except bug report: #3691 #2875
Suggested remediation
Cheesy Mode
One missing subtitle should be a warning, just like a missing thumbnail is a warning.
Easy Mode
Rewrite the documentation:
--no-abort-on-error--ignore-errorsand--no-abort-on-errormatters.--no-abort-on-errorcomes after--ignore-errors, then an error in one download will abort that individual download. So--ignore-errorsshould come afterwards if you always want to finish downloading and preprocessing when possible.Hero Mode
Don't use
ignoreerrorsfor both playlist and individual video errors.Rewrite so the following much less confusing options are present, with appropriate semantics in the code. They have the nice benefit that the order doesn't matter.
Examples
Here are the commands I will demonstrate:
Because I can't paste more than 65536 characters, I will first demonstrate the command the crashes (second one above) and snip some of the highly repetitive lines downloading some of the 100 different auto subtitles.
Provide verbose output that clearly demonstrates the problem
yt-dlp -vU <your command line>)[debug] Command-line config) and insert it belowComplete Verbose Output
The text was updated successfully, but these errors were encountered: