never-ending recording

[akohlsmith]

I had a strange event this morning.

snapshot provided by Viseron. That picture was from a little over an hour ago. There is no movement there, and the info log just showed that the recording kept getting retriggered. I had to quit Viseron to get the recording to stop (and interestingly, also to be able to view the 4.4+GB .mp4, it appears the header is missing information until the recorder stops, which is suboptimal...

How do I help debug this? My config file looks like this. The confidence levels and area are both intentionally "low" because it's not detecting hardly anything at the moment (car goes by, me waving in front of the camera, etc.) and I'm debugging that. I have SecuritySpy watching these same cameras and performing its motion/object detection as well.

logging:
  level: info

object_detection:
  type: darknet
  interval: 6
  labels:
    - label: person
      confidence: 0.6
    - label: bicycle
      confidence: 0.6
    - label: car
      confidence: 0.6
    - label: truck
      confidence: 0.6
    - label: motorbike
      confidence: 0.6
    - label: bird
      confidence: 0.6
    - label: cat
      confidence: 0.6
    - label: dog
      confidence: 0.6

motion_detection:
  interval: 1
  trigger: true
  timeout: true
  width: 640
  height: 360
  area: 100
  frames: 3

recorder:
  lookback: 15
  timeout: 15
  retain: 31
  folder: /recordings

mqtt:
  broker: 192.168.x.x
  port: 1883

cameras:
  - name: cam01
    mqtt_name: cam01
    host: 192.168.x.x
    port: 554
    path: /user=...

(repeat for other cameras)

[roflcoopter]

The never ending recording is probably because your motion detection is quite sensitive.
area: 100 is quite low. If you turn on debugging you can see the motion area in realtime and tune it accordingly.
timeout: true also tells Viseron to not stop recording until no motion is detected.
I should probably implement some sort of max length so this doesnt occur.

Regarding not being able to play the file while its being recorded is due to how the .mp4 container is designed.
I would need to look at another container, did some quick research and probably have to go with .mkv or .ts

[akohlsmith]

I noticed this occurring periodically in my logs, while the motion ended several minutes ago. Might be a clue:

[2020-09-15 15:27:21] [lib.recorder.cam02      ] [ERROR   ] - Timed out
[2020-09-15 15:28:25] [lib.recorder.cam02      ] [ERROR   ] - Timed out

I haven't seen the usual Stopping recording in: x messages, although I do see it for other cameras that have triggered and correctly stopped after the errant camera has been triggered.

Watching the motion_detect debug log, I do not see motion events for the camera that is stuck recording (cam02 here). I don't think it's refusing to stop because it sees motion.

[akohlsmith]

Another clue... it appears that once object detection starts the recorder, the scene must have no motion to stop. I'm not sure that this is good, at least in its current form. I think that the intention is to stop recording timeout seconds after any object detections have stopped triggering when object detection is the source of the recording, not after any motion has been seen.

Alternatively, perhaps the motion trigger settings can be split up so that they have one set of parameters to start a recording and another (perhaps less aggressive) set to stop recording. This would help prevent a windy day moving leaves around from creating gigantic recordings after a vehicle drives by.

Personally I prefer "timeout after last object has been detected" when object_detection causes the recording, and "alternate set of motion detection parameters" when object detection is not used, but perhaps I'm not seeing the bigger picture.

[roflcoopter]

I hear what you're saying.

I think removing the timeout option from motion_detection would be a good idea, and then extend the settings under recorder to set a timeout after last detected object as you describe, and then an optional timeout after last motion detected. Would also be good to implement a "max" timeout for the motion detection to nullify the never ending recording problem.