Open jokke-ilujo opened 2 weeks ago
The previews are already kept as a low resolution storage efficient way to view what occurred, they are saved for a full hour where any full res recordings occurred.
That doesn't address the use cases of say wanting to see other camera at the same timestamp where no full res recording happened. Or knowing a time window (say something happened last night) but no event was triggered so no full res recording at all. This could be addressed with record all retain 1 (or 3 or what ever) but that will put a lots of i/o burden to the disks.
Especially the motion triggers can be tricky to get right to avoid tons of false positives and wild life (neighbour's dog, name your non-tracked object here) stealing something from your property does not require full res recording to give you the peace of mind.
There are just loads of examples where having low res timeline available would be super helpful. Even seeing when a van that appeared on your (or neighbour's) driveway has passed the house previously on the road you masked for motion and object detection to avoid flood of events.
All of those seem like reasons to keep full res recordings tbh, even just motion based recordings
But in any case seems like this request is just to save previews even when recordings are not saved
I can definitely see a benefit to having previews saved regardless of camera activity as a safety net, but I'd argue that motion tuning would likely solve the issue you're having. I used to have hours of recordings where nothing happened because I didn't want the motion sensitivity to be so low that it missed an important event. However, after doing some trial and error, setting up motion masks, and using home assistant to change motion sensitivity based time of day and wind speed, I've cut my saved recordings in half and can't say I've ever missed legitimate motion.
That doesn't address the use cases of say wanting to see other camera at the same timestamp where no full res recording happened. Or knowing a time window (say something happened last night) but no event was triggered so no full res recording at all.
It seems like a motion sensitivity issue to me if something happened but no recordings were saved.
Even seeing when a van that appeared on your (or neighbour's) driveway has passed the house previously on the road you masked for motion and object detection to avoid flood of events.
Constraints can be set for events/review items in a manner that still allows motion recordings to be saved. I'd argue that you shouldn't have a motion mask on the street if you think you'll ever be interested in vehicles driving past. I would just make a custom zone that excludes the street and make that zone required for a detection to appear on your review screen.
Storage is relatively cheap. I'd rather have full resolution recordings and have to buy a new drive every once in a while than have potato-quality video if something bad happens.
Describe what you are trying to accomplish and why in non technical terms I want to be able to have main stream and sub stream recorded with different retention rules so that I can have my sub stream which is used for detection also recorded continuously with long retention period while event based retention would apply to the high-res main stream.
Describe the solution you'd like Most user friendly option would be to create new record_mode[all, motion, active_objects] roles for inputs. This way the current behaviour would be simple to keep but would allow something like:
Describe alternatives you've considered Creating duplicate cameras in separate group with only sub stream defined as path and separate recording config with it's own retention. This makes the config/ui messy and requires lots more effort each time changes happens to track them in multiple places.
Having input specified in the record config. That would require some way to identify stream types in the input list like:
Additional context I can't be the only one who would like to have the low resolution sub stream recorded continuously/on motion with decent retention period just in case and get the high resolution clips for any highlighted events being it (motion or) object detection. This would save a lot of storage capacity and wear and tear as the low res sub stream takes significantly less space/io. The proposed solution with mode based roles would make it simple to address individual preferences which stream they would like to keep for different modes while the existing deployments would keep working with the simple 'record' role as it has so far.
Something to consider is if the community wants to support mixed config, so for example sub stream having 'record_all' role and main stream having 'record' (this would be catch all for any mode not specified in the camera config) role where defaults are applied. Or require either 'record' only role or all wanted modes defined within camera config, F.E.
I'd be willing to try to find some cycles to help implement this if needed in case the feature would be considered.