moonfire-nvr

> make absolutely certain that your USB to SATA adapter has proper UAS support in ARM Linux How does one do that? I've been bitten with block-level and then filesystem-level errors, so I just recommend always disabling UAS. [1] But if you have a good way to make sure UAS is fully reliable, I'd love to update my recommendation. [1] https://github.com/scottlamb/moonfire-nvr/wiki/System-setup#...

I don't know who needs this kind of precision, especially on a Pi. But there's often a need to improve on the Pi's sucky out-of-the-box time experience. It doesn't have a battery-backed real-time clock. After a power outage, it will boot with time that's hours behind and then step the clock after the network becomes available. So a nice middle ground is to buy a separate RTC and attach it via the I2C GPIO pins. The modules are ~$10 including shipping. I wrote up the software setup recently here: https://github.com/scottlamb/moonfire-nvr/wiki/System-setup#...

Yes, I have a Pi4 booting off a SSD on a USB-SATA bridge. No SD card installed. This graduated from beta about a year ago. [1] Btw, since you brought up USB: disable UAS [2] when using cheap USB-SATA bridges! UAS is regularly recommended for performance reasons, but I've gotten block-level errors (eg those below) and filesystem corruption with UAS multiple times and never with UAS disabled. I've seen enough similar reports on the Internet to think it's better to just disable UAS. Sep 22 17:26:01 nuc kernel: sd 4:0:0:1: [sdb] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT Sep 22 17:26:01 nuc kernel: sd 4:0:0:1: [sdb] tag#2 CDB: Write(16) 8a 00 00 00 00 01 4d b4 c4 00 00 00 03 b0 00 00 The Linux kernel has explicitly disabled UAS for some of these chipsets, but clearly not all of the offending ones. I'm not sure what you'

You probably want to mount a weather-resistant camera outside. You could buy an eg Reolink security camera for this fairly cheaply. [1] Then you can stream the video to a Raspberry Pi 4 + Coral USB accelerator, an nVidia Jetson nano, or the like and do analysis there. [Edit: oh, I missed that the Vizy has an outdoor enclosure available. Still, it's extra $60 and is huge/ugly. The off-the-shelf IP camera + separate computer for analysis should be cheaper and IMHO better.] I'm working on a Free Software security camera NVR system. [2] I have a pretty solid core recording engine now and am just thinking about what the API for on-NVR analytics plugins should look like. I'm imagining a Python API where you write some coroutine that can iterate through decoded video frames (either live or backlogged) and make calls to your favorite ML framewor

I use it in a network video recorder. https://github.com/scottlamb/moonfire-nvr/blob/master/design... Data in a flat file would be much less efficient, and a SQL server (eg PostgreSQL) would be more for the administrator to deal with. SQLite's a nice sweet spot. I've thought about using a key/value database (either a BTree one like SQLite uses under the hood or a LSM one like RocksDB). It'd be faster and less total code. But SQLite's too convenient to give up. The SQL interface is nice for debugging in particular. And it's already plenty fast enough, so my time's better spent adding some glaring missing features and better UI.

failure [1] is still state-of-the-art, even though it's deprecated. It will get you backtraces (if RUST_BACKTRACE=1 is set), which nothing else will. I'm waiting until there are stable built-in backtraces [2] to switch to something else. I recently tweaked my application's failure reporting [3] to go from this embarrassing thing: E0211 073750.559 main moonfire_nvr] Sys(EROFS) to the more useful: E0211 111025.109 main moonfire_nvr] Exiting due to error: Failed to open dir /home/slamb/mymount/sample caused by: Unable to open meta file caused by: EROFS: Read-only file system (set environment variable RUST_BACKTRACE=1 to see backtraces) I should have thought long ago to advertise setting RUST_BACKTRACE=1 right in the error message, but better late than never. [1] https://crates.io/crates/failure [2] https://github.com/r