Corrupt File Warning

[githottub]

I didn't put [Feature Request] in the title because I'm not sure how difficult it would be or how interested you'd be in implementing it.

Problem: Sometimes a video at a particular resolution will be corrupt. For example, on NHK World it seems ~10% of 1080p videos are corrupt, whereas ones at 720p or lower are almost always OK.

Example: https://www3.nhk.or.jp/nhkworld/en/ondemand/video/3004808/

You can see that initial analysis indicates this video at 1920x1080 should have a Filesize of 3.60 GB. However, when the download is started, it's discovered to be only 1.59 GB. If the download is allowed to complete the resulting file will be corrupt and unplayable. I know this for a fact and have confirmed it several times even using other download methods. It's definitely the source file and, as mentioned above, is a common problem on this website for some 1080 files. I imagine there must occasionally be corrupt files on other websites as well.

Desired Solution: Some logic would be implemented to detect the filesize difference, notify the user the file is likely corrupt, then prompt the user to choose: continue anyway, cancel, or (if possible) automatically switch to the next best quality and continue downloading it instead. Lastly, for users that tend to queue up a large list of URLs for downloading then walk away, you could possibly also implement a feature in Settings where the user could select to always allow the app to automatically handle this entire situation without interaction from the user.

[ErrorFlynn]

Desired Solution: Some logic would be implemented to detect the filesize difference

Unfortunately, I can't think of any way to do that. The only way to see if there's a difference is to start the download, and even then, the difference could be just due to the initial estimate being wrong. There doesn't seem to be a reliable way to detect when your scenario occurs.

Edit: To be clear, what I meant to say is that in most cases the initial file size estimate is wrong, but the file isn't corrupted, so the estimate being wrong is not a reliable indicator of the file being corrupted.

2nd edit: I just looked at the formats list for your example video, and the VBR is 10269, which seems too high for 1080p video encoded for the web. That may be a better indicator that the file is corrupt. I'll look further into it, maybe something will come out of this after all (no promises).

[githottub]

That bit rate is correct. NHK posts many 1080p videos with ~10K bitrate. The only way I'm able to manually know a file is corrupt is to look at the initial file size shown before d/l starts (which IS what the final good file should be) and then look at the estimated file size after it starts downloading. If the file is corrupt, the latter file size will be lower and inevitably the finished d/l file won't play.

[githottub]

Closing since a) it would be difficult to implement and b) NHK has subsequently stopped providing the high bitrate 1080p videos which were the source of the issue.