[Support]: post/pre capture does not work

[Sloth-on-meth]

Describe the problem you are having

hi! i setup post_capture and pre_capture to be 10 seconds each. this does not seem to work, resulting in cutoff clips.

Version

0.10.0-B912851

Frigate config file

record:
  enabled: true
  retain_days: 0
  events:
    pre_capture: 10
    post_capture: 10
    retain:
      default: 10

Relevant log output

n/a

FFprobe output from your camera

/

Frigate stats

{
back: {
camera_fps: 5,
capture_pid: 239,
detection_fps: 11.8,
pid: 231,
process_fps: 5,
skipped_fps: 0
},
detection_fps: 12,
detectors: {
coral: {
detection_start: 1637138416.91632,
inference_speed: 8.74,
pid: 225
}
},
front: {
camera_fps: 5.1,
capture_pid: 237,
detection_fps: 0.2,
pid: 228,
process_fps: 5.1,
skipped_fps: 0
},
service: {
storage: {
/dev/shm: {
free: 3201.8,
mount_type: "tmpfs",
total: 3221.2,
used: 19.4
},
/media/frigate/clips: {
free: 65039.4,
mount_type: "ext4",
total: 3936911.9,
used: 3671816.5
},
/media/frigate/recordings: {
free: 65039.4,
mount_type: "ext4",
total: 3936911.9,
used: 3671816.5
},
/tmp/cache: {
free: 15704,
mount_type: "ext4",
total: 117608.4,
used: 95886.1
}
},
uptime: 1191,
version: "0.10.0-b912851"
}
}

Operating system

Other Linux

Install method

Docker Compose

Coral version

USB

Network connection

Wired

Camera make and model

Reolink 410 / 520

Any other information that may be helpful

seems like this beta update broke it.

[blakeblackshear]

Good catch. I do think I broke this.

[Sloth-on-meth]

Good catch. I do think I broke this.

yay, finally something i didn't break myself :P it is quite interesting to see how precise the motion detection is :)

[workshopninja]

New user here - all setup and working as expected but I am having this issue too. Glad I’m not doing something wrong - keep up the amazing work - the lack of google coral usb sticks is testament to your work…

[workshopninja]

Is it my reolink cameras that are not streaming in sync - or is it a frigate problem that my recordings are starting late?

[workshopninja]

Interestingly the videos in “recordings” have caught the beginning of the “action” but the “events” recordings are late…

[workshopninja]

Since enabling continuous recording - I am capturing the beginning in both events and recordings.

[Sloth-on-meth]

same here. would be great to have it work without continuous ofcourse

[Iceman248]

With the new version and I can now let the recordings be cached into RAM, I noticed that although capable, the beginnings are cut off. 5 second default seemed like enough, but now after changing to 10, stayed the same, so now I know it just simply doesn't work.

[NickM-27]

@Iceman248 Have you changed the record mode to all ? As discussed above that works for now until this is fixed.

[blakeblackshear]

The default retain mode for events is motion. When that is set, it will only retain segments that contain some motion regardless of what your pre_capture is set to. Either those pre capture segments didn't contain motion or the timing is different between your detect and record streams.

[Iceman248]

@Iceman248 Have you changed the record mode to all ? As discussed above that works for now until this is fixed.

I didn't read that anywhere, but "all" doesn't work for me. I'm not willing to have that kind of hit on these drives. That's why I didn't even enable recording until this latest version allowed the 24/7 recording to RAM. I'd rather just wait until fixed. It doesn't happen every time, probably most of the time it looks like, as sometimes I get 10 or 5 seconds before the active object gets snapshotted.

[Iceman248]

The default retain mode for events is motion. When that is set, it will only retain segments that contain some motion regardless of what your pre_capture is set to. Either those pre capture segments didn't contain motion or the timing is different between your detect and record streams.

I have mine set to "active_objects". Does that work in a similar way? Either way, like just mentioned in previous post, sometimes I do get 5-10 seconds before the snapshot. Timing should be the same in detect/record streams, can't think of any reason why it'd be different.

[NickM-27]

@Iceman248 yes active_objects would work in the same way, if the active object started at the beginning of a segment then the previous recording segment would be dropped and the pre_capture would not be included. detect / record streams can easily be slightly off just as the camera sends them not in perfect sync with each other.

[blakeblackshear]

After reviewing, this looks to be working as designed. The pre/post capture is used when setting the timeframe of the event, so it just modifies the start time of the event based on pre_capture. The retention mode for events applies to pre/post capture just like any other segment. By default, the event retention is set to motion, so only segments with motion will be retained.

record:
  enabled: true
  retain_days: 0
  events:
    pre_capture: 10
    post_capture: 10
    retain:
      default: 10
      mode: motion # <----- default

You can increase the pre_capture, but if those pre_capture segments don't contain motion, they will be deleted because they don't meet the retention criteria.

If you want to retain pre_capture without motion, you need to use all for the event retention. The downside is segments in the middle of long running events will also be retained. If you have a parked car for 4 hours, you will get 4 hours of segments. You can't have it both ways.

The segments are 10s long, so you will get 0-9s of pre_capture based on when the motion starts in that segment.

[Iceman248]

Thanks, guys. It sounds like you're saying that even if I set to active_objects, I would still get whatever I set as pre-capture if it involved motion, correct? That may be what I am seeing. Sometimes there is motion and I get the pre-capture and then when I don't get it, I'm thinking there probably wasn't motion. Is the motion applicable to only the areas that motion isn't masked off for? What about specific object masks? Would that prevent motion that prevents pre-capture?

[blakeblackshear]

Motion masks are for motion only and object masks are filters for detected objects. They work completely different.

It is impossible for motion in areas with a motion mask to create motion that would cause a segment to be saved. You won't see motion boxes in the debug stream in masked areas.

Objects can and will be tracked even as they go into areas masked for motion. You can have an active_object that has moved into an area completely masked for motion.

More details: https://docs.frigate.video/configuration/masks#further-clarification

[PovilasID]

I have a camera that is pointed at a path but camera view is occluded by a spruce and it takes people just long enough that on the other side they are detected "again". I set pre and post capture to 15 sec but I still get 10 sec clips on detections. I get why footage with no movement is deleted but I was expecting pre/post_capture to increase the margin of footage before and after motion.

[NickM-27]

The retention will only ever be what your config is set to keep, if the segment has no motion it won't be kept. That being said, based on what you describe you may want to increase the value of max_disappeared slightly to make that detection a part of the same event

[PovilasID]

max_disappeared was the setting I was looking for! Both clips are joined and longer. There are some issues still there if objects are occluded first time they enters the frame the clip does not start at optimal point in time but I keep a continues record of last 24 hours to fall back too and it cut the notification spam a lot. I have quite a lot of trees in frame that move almost 100% of the time, but I presume you were referring to the movement of the object.

[Timdawson264]

@blakeblackshearwould be possible to add a setting to keep more segments in the cache? my cache is in memory and that would save writing empty segments to disk, but more pre/post in high-motion areas would be nice without just recording motion to disk. Also thanks for all your work on such a cool project.

[NickM-27]

@Timdawson264 can you elaborate? Are you suggesting frigate should purposely slow down its logic moving segments from cache to disk so that more segments are in the cache at once?

[Timdawson264]

@NickM-27 yes. so that we can actually make pre work without needing to use mode: motion. I currently have pre: 120 and the cache segments hover between 4-6 files per camera. I was thinking could the segment garbage collection be configured for the cache such that this could be changed in the config. perhaps automatically using pre/segment_length.

[Timdawson264]

Ill send you a PR once i have a dev env going, my plan is to set keep_count in move_files based on the pre lengh and min 5.

[Timdawson264]

I knew that sounded too easy.

    if (store_mode == RetainModeEnum.motion and motion_count == 0) or (
        store_mode == RetainModeEnum.active_objects and active_count == 0
    ):

if store_mode is active_objects, but the segment has 0 active, it can't get recorded. so pre still doesn't work.

[blakeblackshear]

You can't predict the future. There isn't a way to know that an event is about to start in 120s.

If you have motion mode enabled then you should already have any segments where pixel values changed.

If you want more precapture, then you could just freeze the first frame and show a static image for the first 120s. /s

You really just need to use all mode if you want to save video of a still image.

[Timdawson264]

@blakeblackshear I got pre_capture working nicely, and I need to fix the event query to get the post_capture working.

Yes, you cant predict the future but it's simple enough to get a large enough buffer of segments to use when an event occurs. its quite nice to have the pre and post fotage of an event especially when the model might not detect for some time due to obstructions or what have you. i mean at the end of the day i would like to just get pre and post functioning as expected.

[NickM-27]

it's simple enough to get a large enough buffer of segments to use when an event occurs

It's not a simple problem to solve given the other environmental issues, there are a number of users that have seen issues with recordings not being moved fast enough and we have just recently gotten things in a good place. This type of change would be working against that directly. Also, all of the recording files in this buffer would not be kept if frigate crashes, lost power, or was restarted which is another issue.

[blakeblackshear]

If the user is exclusively using event recordings (retain days set to 0), then all that has to be done is waiting a little longer before deleting segments from the cache. Then, if an event is backdated, the appropriate segments (motion or all) will be included in the event since they overlap with the time range.

If a user has specified that they want motion retain mode for events, then the segments that are in the pre/post capture period that don't contain motion should be deleted.

You can already essentially get this behavior by retaining 1 day of any motion.

[NickM-27]

The frigate UI is currently being rewritten for the next version of frigate (0.14). As part of this, "previews" (low res / low fps videos) are kept to make scrubbing very footage fast and easy. Previews also bridge the gap for any time that a recording for an event wasn't kept. Given that pre / post capture is working as intended and the new features will make it even less of an issue when reviewing, closing this