scottlamb
commented
4 years ago The problems encountered is that the list of videos in the Web interface are empty and have the infinity symbol.
I think this means that you have a recording with exactly one video frame. RTSP streams don't give the duration of each video frame; they just give its starting timestamp. So Moonfire NVR calculates the duration of each frame using the time of the following frame and assumes 0 for the final frame. You should see a total recording duration of 0 if and only if there's only one video frame in the whole recording. Duration of 0 would cause it to show frames per second of infinity.
This much is working as intended.
I would expect that older recordings would be removed to allow room for the new recordings. ... Perhaps the disk allocation to the camera also serves as a working area for the MP4 creation and with the working area at capacity, the MP4 stream halts?
That's right. Segments that are currently in progress aren't accounted for. guide/install.md says "Leave a little slack" for this reason. I think the guidance of "100 MB per camera" is incorrect in your case. I see 18.2 Mbps in one entry in your screenshot. The first recording in a run might be up to 2 minutes long; that'd be 273 MB at that rate. There should be at least that much slack.
Actually, I can't remember off the top of my head, but segments that are fully written to disk but not flushed to the SQLite database might also not be accounted for. So higher flush_if_sec might further increase the requirements for slack space.
Currently the code will stubbornly try to write each video frame (to the OS's buffer) right after it's received it, on error retrying once per second forever. It doesn't do anything like trying to free more old recordings if it seems full. So yeah, it's pretty much expected for it to get stuck until you free up some space.
The docs at least can be improved.
As for code changes...I could modify it to account for the segments being written. The catch is that I don't want to force frequent database flushes (increasing load on the SSD), so say freeing up exactly as much space as needed for the next video frame doesn't seem like the right approach. It'd require some thought, which is why I've punted on it so far.
One idea: it can maintain an estimate of how much slack space is required for what's in flight. After a write hits ENOSPC it could abort the current segment, wait some cooling-off period, increase that estimate, ensure there's enough space, and try again. Although it might go through this whole cooling off period a couple times on every restart, which would be annoying. Every idea I've had so far has had some caveat to it.
I'd be interested to know if there's some other NVR system that solves this better and how.
Also, if I select one of the early recordings, when there was sufficient disk space, my attempt to view it is prevented after displaying the first second.
This probably happened because the recording was deleted as you were viewing it. You could confirm this by restarting the daemon with the --read-only argument. Then everything that's in the list should stay viewable as long as you're running in this mode.
This is a UI problem...as I've mentioned the current UI is really a prototype. I'd like to have a slick scrub bar UI (#32). I'd expect the scrub bar to shrink and your viewing position jump if video is deleted as you are viewing it. Right now if one of the recordings backing a .mp4 file is deleted, your next HTTP request on that .mp4 file will fail. Or even your current HTTP request can be abruptly aborted if it reaches a byte position that requires a disk file that no longer exists.
Also, when there is a filled up database, what can a user do to remove files and/or entries? How about a server command that the administrator would run to "flush" older content with settings such as percentages to minimize loss of older recordings?
You can shut down the server, free up space via moonfire-nvr config, and restart. (This procedure didn't used to work; see #65. But it should be fine now.) There's no API to do this yet on a running server, but I expect to implement one as part of #35.
I had a power outage yesterday and the Raspberry Pi was not on a protected circuit or have shutdown protocols established (yet). I found my database corrupted...
I want the database to be robust to power failure. No UPS or "proper" shutdown required. Does your Raspberry Pi have journaling enabled on its filesystem? You can check via dumpe2fs. If it does, please open a separate issue about this corruption with more details. It shouldn't happen.
Looking at SQLite's docs, I wonder if I should upgrade from pragma synchronous = 2 to pragma synchronous = 3. Otherwise I think Moonfire NVR does about everything possible to maintain integrity.
It would be helpful to have some way to preserves,export, and import entries so that I do not have to manually enter everything all over again.
Feel free to add a note on that (sub)feature at #35. That'd certainly make sense as part of a good config UI.
jlpoolen
It looks like I may have killed my session when I negligently closed my puTTY session to the Raspberry Pi. I tried starting up and the console displays continual error messages:
Running on a Raspberry Pi 4. I have only one camera designated and I allocated 2 GB of space for saving recordings at /var/tmp/video/garage_west. My camera is at maximum resolution (2560 x 1440) and frames per second (30). Yes, this is an unreasonable capacity setting given the frame size and maximum number of frames per second. But I'd like to learn now, rather than later, how a "full" condition is handled.
The problems encountered is that the list of videos in the Web interface are empty and have the infinity symbol.
I would expect that older recordings would be removed to allow room for the new recordings.
Also, if I select one of the early recordings, when there was sufficient disk space, my attempt to view it is prevented after displaying the first second.
Perhaps the disk allocation to the camera also serves as a working area for the MP4 creation and with the working area at capacity, the MP4 stream halts?
Also, when there is a filled up database, what can a user do to remove files and/or entries? How about a server command that the administrator would run to "flush" older content with settings such as percentages to minimize loss of older recordings?
I had a power outage yesterday and the Raspberry Pi was not on a protected circuit or have shutdown protocols established (yet). I found my database corrupted, tried to export my camera and disk allocation using Sqlitebrowser. I ended up creating a new database and then using the Sqlitebrowser (while no moonriver-nvr process was running, of course) tried to import my settings. I currently have 4 cameras and expect to end up with 10 or 12. It would be helpful to have some way to preserves,export, and import entries so that I do not have to manually enter everything all over again.