Closed mvglasow closed 3 years ago
KillerInk
commented
4 years ago sounds to me like the next race condition. are the last stored images corrupt? i think this could get fixed with reducing the pressure to the single core while a capture is in progress. simplest solution is to keep the capture images in the module as long the interval runs, and on stop update the FileListController.
mvglasow
commented
4 years ago The last image file does not appear to be corrupt. The image itself looks OK, and so does the EXIF information. I also did not notice any corruption in the preceding ones.
On March 2, 2020 6:10:36 AM GMT+01:00, KillerInk notifications@github.com wrote:
sounds to me like the next race condition. are the last stored images corrupt? i think this could get fixed with reducing the pressure to the single core while a capture is in progress. simplest solution is to keep the capture images in the module as long the interval runs, and on stop update the FileListController.
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/KillerInk/FreeDcam/issues/108#issuecomment-593222218
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Today I did the endurance test for interval mode, with a 2s interval, shooting for 6 hours non-stop. At some point, however, FreeDcam simply froze and stopped responding.
To reproduce:
Expected result:
No fuss, one image every 2 (or so) seconds
Actual result:
After about 4h 20min, FreeDcam stopped responding altogether. When I killed FreeDcam and tried to re-launch it, it crashed—should be visible in the log as well. Original PID was 1018, PID on relaunch was 8320.
Environment:
Further information:
Logcat here: alogcat.2020-03-01-16-45-27+0100.txt
The last image was taken at 16:26:22 The image looks OK; unfortunately the events had already rotated out of the log by the time I got around to saving it.
What seems to have happened: Apparently at some point the image did not get saved properly (hardware failure or just some kind of random hiccup in the OS—it happens with that kind of heavy usage). FreeDcam tries to read the picture it has just taken, which failed in this case. That sent FreeDcam into an endless loop of trying to re-read the picture. Having some kind of fail mechanism (e.g. skip the update this time, or show a blank image) would probably have solved this. In this case, we would lose one picture, but IMHO that is still better in a set-and-forget use case than the app stopping working altogether.