lbdroid
commented
7 years ago This is actually a symptom of a much stranger issue. One of the libraries I am using to manage the ffmpeg process was apparently coded by three chickens and a chimpanzee. Basically, there was no locking on the function where ffmpeg is actually executed, AND, the function that checks if it is "finished" executing, was hopelessly broken (and not to mention altogether redundant). So what that means is that it could try to execute several times in rapid succession, one of which would succeed, and several of which would fail at various stages. If it makes it far enough to have a few fail, then those failures will trigger the notification to show "stopped". Another consequence of this is that the handle to the actually running ffmpeg process would be lost -- which means that while it will still be running (GC won't kill off shell commands!), we wouldn't actually know about it, so it would repeatedly try and fail (because the kernel locks the video device out from subsequent threads).
Another consequence of this is that the filesystem and database cleanup threads won't run when the notification indicates that recording is stopped, which means that the ffmpeg process could eventually die as a result of inadequate storage space. I never actually got it to the point of stopping though, since I have a default minfree value of 25%, which in my case, is 64*0.25=16 GB, and at 40 MB/min. 16000/40 = 400 minutes, or 6.67 hours.
I've got the necessary changes into my source tree and will be testing this evening, and will get an update posted once it is confirmed.
Sometimes, the notification shows "recording stopped", when in fact, it is actually recording. This probably happens during auto-start if there are multiple attempts to start that conflict. Going to have to either lock around the notification update, or maybe it would be best to just check the state and update the notification occasionally.