Open mangoducksparkles opened 3 years ago
header: Last-Modified: Mon, 13 Nov 114322 14:12:21 GMT
This is shown with --print-traffic. Year 114322 seems to violate RFC specification (= 4 digit).
Since this is not user input data, and probably very rare, I guess no workaround code will be made or needed to prevent exception termination.
Checklist
Verbose log
Description
Sorry, I'm unsure if this is truly a bug or worth fixing. When I try to download this video, it successfully downloads, but then throws an error and (if part of a playlist) stops the download process.
The file is correctly named with the
upload_date
(see the-o
argument in the System config), and it only fails when it tries to set the file modification time (passing the argument--no-mtime
bypasses this issue). Therefore, I'm guessing that the time metadata downloaded from youtube is correct, and that there is a problem with the function that sets the modification time. However, the--no-mtime
documentation states that it uses theLast-modified header
, so perhaps that is different than theupload_date
, and this is just a case of youtube having some bad metadata. Sorry, I don't know.If this is just the case of bad youtube metadata, I don't know that anything needs to be done. This can be bypassed with
--no-mtime
, as I mentioned, and I assume that-i
would allow the playlist to continue downloading in case this happens again. However, if this is an actual bug with the function that sets the modification time, then that should probably be investigated. I'm sorry, I don't have any suggested solution.