Open scottlamb opened 6 years ago
One thought here is to allow video range exceptions:
We’d use the provisionally locked state when an event of interest (motion detection, audio detection, whatever) happens. If there is no specific end-event, we’d create ranges of a certain length (perhaps configured on a per event-type basis). If there are end events we’d use this. In all cases it would probably be good to allow a margin-before and margin-after to auto-expand the locked range so as to capture some before the event, and some after the termination event.
So even if the user would not inspect their recordings every day the provisionally locked intervals would prevent erasure for a while. In future we could email alerts: a) when they get recorded (but perhaps no more than once a day), and (b) when they are “x” time away from being “released” unless truly locked.
All of this leads to a need for recording and storing “ranges of interest”. We probably should distinguish different kind of ranges:
Most of the above would either get no locked (provisional or not) state, but others might automatically receive a provisional with pre-configured expiration. user defined would receive either a provisional or permanent lock, at the user’s discretion.
There probably needs to be a distinction between event start/stop time range, and associated recording/lock range (if we do margins).
Both event ranges and recording ranges might be used in a UI (scrubber or otherwise).
Dolf Starreveld
email mailto:registration@starreveld.com
I agree with idea of having three states: hard vs soft vs unpinned.
Besides keeping the ranges somehow, I think we should denormalize it into each recording and have an index to use for auto-deletion, so even if there are a huge number of pinned recordings to skip over, auto-deletion remains efficient.
All of this leads to a need for recording and storing “ranges of interest”.
I have a draft schema for "signals" such as alarm on/off, motion on/off, and audio on/off; see #28. Maybe manual ranges could be put in the same format. I was thinking there'd be a separate "annotation" concept that'd let you associate some text or something with a point or maybe range. E.g., if you go through all your motion detection events, you could mark one as "Dolf arriving home" to keep track of what you've already checked. I'd imagined that being a separate table, but maybe that's silly. Maybe there should only be one range concept.
FIFO video segment deletion has served me well, but relying on is alone started to not be good enough. I now instead need some segments to be explicitly deleted (ie: https://github.com/scottlamb/moonfire-nvr/issues/39).
Prior to deleting stuff though, it'd be great to have "pinned" recordings capability in place, so I could rest assured that important recordings won't end up getting deleted just because my deletion criterion was a bit too broad (opsie).
I see both issues (#38 and #39) are correlated and with great discussion around the topic, however they are quite old now. I have a few spare cycles I can commit to help on the Rust side (maybe play a bit with js), before doing so I want to ask whether there has been any other thoughts/considerations into this and next steps in mind.
I might missed some context, so take it with grain of salt. Following on the direction of events having its unique identifiers delimited by a time span (start /end time), we could augment it with a blocking_deletion
state flag, this could be automatically set on
by default.
on
deletion logic would avoid any recordings within that given timestamp (leave them alone).off
deletion logic would delete the recordings, likely delete the event as well to not leave a dangling reference or an alternative in case we wish to preserve events despite recording have been erased.That's all for now, reviving the thread :)
I have a few spare cycles I can commit to help on the Rust side (maybe play a bit with js)
Help is most welcome in both areas. If you're looking for a JS thing, I'm a bit stuck on #286, which is really unfortunate. Lots of stuff to do all around really. But back to this issue:
before doing so I want to ask whether there has been any other thoughts/considerations into this and next steps in mind.
No, I haven't given it much thought in quite a while! But here's a bit more about the current state:
Currently Moonfire NVR deletes recordings in strict FIFO order. It'd be nice to be able to explicitly say some section of video should be retained; also to have automatically increased retention when there's a motion detection event.