I've noticed with corrupt and incomplete video files, generally when the duration of the file doesn't match the real duration of the file, the thumbnail extraction stalls for a very long amount of time as ffmpeg tries to complete the extraction! This seems to be due to the filters expecting data from the inputs at each time code, and if any of these don't have data, it stalls waiting for it. There does appear a timeout, but it's incredibly long. 馃憥
To counter this, we can first check each of the timecodes individually, and check for actual data! 馃憤 This works way quicker, and will fail immediately if the data is missing!
If we find data missing, we have three options:
1) Skip all thumbnail generation for this file. eg. 0 screenshots.
2) Generate as many thumbnails as we can until the missing data, and then update the numOfScreenshots for that file. eg. 15/20 screenshots.
3) Change the duration of the file to be until the first missing data, and generate the full numOfScreenshots for the file. eg. 20 screenshots.
Thoughts? 馃挕
Is it possible to insert blank screens where screenshots were not found? That seems like it would be the best solution 馃槃
I suspect some corrupt files have local corruption (say at 50% mark there is 20 seconds of video that's missing, while all the rest is present). In that case, we'd have a full filmstrip except for a single missing screenshot - a black rectangle in its place (best scenario), rather than an incorrect duration as in option 3, missing screenshots as in option 1, or only half the screenshots as in 2.
Though this may be a bigger challenge.
Since I've started working on the app over a year ago, I've always been time-constrained. I always have more ideas, bug-fixes, and edge-case-handling intentions than I have time for, so I opted to work on the features that would affect the most users.
The current bug you describe is worth fixing -- using the new ffmpeg extraction we have I scanned in a folder with 300 files, and it halted at 58%. I suspect a file is corrupt (I didn't find the time to investigate further). The easiest thing to implement is likely option 1 - just skip the file generation.
Thank you for your attention to detail and constant testing of edge cases 馃檱
If there are particular features / bug fixes you'd like _me_ to work on - just let me know and I'll make them a higher priority on my todo list 馃憤
I was having the similar experience - mine would halt at 43% and I confirmed it was corrupt files! I've implemented option 1 locally, and I'm testing it out! If it works, I will add that initially and the look into your suggestion! I think it can be done! 馃憤
Regarding priority, I would be very grateful if you get the time to review my overall idea in #73! 馃槃 (See my comment)
Following up on this, my implementation has much improved this! I've opted for skipping corrupt videos so far, which will additionally point out the problematic files so I can debug! 馃悶
I'm going to investigate #103 some more, and then PR the changes for this issue! 馃憤
Closing thing for now as #109 has merged! 馃憤
May return in the future to add the more complicated solutions! 馃挴
Most helpful comment
Closing thing for now as #109 has merged! 馃憤
May return in the future to add the more complicated solutions! 馃挴