"pinned" recordings

[scottlamb]

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.

[dolfs]

One thought here is to allow video range exceptions:

• state=locked: permanently prevent deletion of any samples covered by such a range
• state=provisionally lock: a timestamp of provisional lock would be attached, and some system wide setting would change this state to “unlocked” after a certain time frame
• state=unlocked: These are not necessarily, but they could be implemented to simplify code and then periodically garbage collect these away

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:

• event: alarm on/off
• even: motion on/off
• event: audio on/off
• event: user defined (this is when a user manually wants to identify a region of interest)

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:[email protected]

[scottlamb]

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.

[ldfsilva]

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.

• when on deletion logic would avoid any recordings within that given timestamp (leave them alone).
• when 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 :)

[scottlamb]

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:

• we have today backend support for "signals" (#28): basically a timeseries of enumeration values that could represent motion detection state (e.g. "motion" vs "still" vs "unknown") or burglar alarm state ("disarmed", "armed_home", "armed_away", etc.) or anything else really. Some signal state could be tied to a particular recording being pinned. There's no real UI for signals yet. I have some signal-based stuff for the list UI half-finished in a working copy somewhere...
• I've thought about (probably additionally having rather than instead having) an "event" concept that's more similar to what you're describing: each event having a distinct id and arbitrary key/value pairs, maybe some understood by the UI, maybe some just with meanings assigned by the user / third-party integrations. Yeah, pinning could be part of that. But events don't really exist today in the schema.
• We do schema changes occasionally (on version 7 now). It's some dev effort to do schema changes (e.g. writing/testing the migration logic) and some user effort to upgrade, so I like to let them soak for a while on a branch, test them thoroughly, and maybe batch together a few changes into one schema version bump.