search

silvanmelchior / RPi_Cam_Web_Interface

A web interface for the RPi Cam
MIT License
1.53k stars 493 forks source link

motion not sending a stop, max_capture and losing footage #102

Open spikedrba opened 9 years ago

spikedrba commented 9 years ago

Hi there,

I'm having some issues where for whatever reason motion isn't sending a stop capture. This seems particularly frequent when there is a change in period and the change of settings seem to trigger a recording (even tho I turn motion off before changing settings).

As a result for example this morning I had a 1.9GB file and growing. I caught it on time, but if I didn't and it actually got into the "busy period" I'd probably lost footage. While I'm trying to determine why motion is doing that, I was looking for alternative solutions and ran into Max_Capture, which would put a limit to the runaway recording. The problem however is that if I really had any legit prolonged period of movement, longer than Max_Capture, I would still end up losing footage as Motion would not send another start command since internally it's still going.

Is that a correct understand of how that'd play out? Something I'm thinking is to issue a stop and immediately another start as a way to truncate the file basically. The other benefit of this is that longer recordings would be split up and not be a massive CPU hit once they get passed on to MP4Box.

thoughts?

roberttidey commented 9 years ago

Yes. Both external motion and internal motion will only issue a start after they issue a prior stop.

The schedule Max_capture starts a timer after issuing a start to raspimjpeg and then will issue a stop itself if no stop request has come in from motion. When the stop eventually come in afterwards then schedule will ignore it.

I think there is more opportunity for altering this behaviour with the internal motion detection. E.g. at the moment a stop received from outside like pressing the web button or a max_capture time out does not affect the internal detection which will continue to look for a stop condition. It would be fairly easy to change this or have a flag so that a capture stop command, rest the internal motion detection back to the off state and it would then retrigger if motion detection conditions persisted. I can see a case for wanting either behaviour so a flag may be the way to handle that.

spikedrba commented 9 years ago

agreed, that would be desirable/good design. I've been unfortunately pulled elsewhere and not having been able to make any progress with the algorithm I'm stuck using external motion detection as I need despeckle to filter out noise from the grass/wind. If I manage to find some time I'll try to prototype this in python and it works share it/try an implementation in C.