I would imagine so. I'm not certain though, sorry. It wouldn't hurt to try it out and see how it performs though.Has the underlying code been patched to increase reliability?Ok, now I get it. However the true solution would run a watchdog as a safety measure should the space fill up. At the time, the original author refused to make one to avoid deleting potentially "important" recordings, an opinion I disagreed with since files are of no use if they can't be accessed.You mentioned issues with the SD cards getting corrupted because it wouldn't erase files. You could try Google Drive with regular MotionEye, assuming you'd want to pay for cloud storage. I mentioned it in case you still have issues with SD cards/file erasure with MotionEye. Just letting you know you have options if MotionEye still has issues with local recording.I'd go with the fully CLI one.Yup. Ideally install an OS without additional tools/software (I believe there's a light version of Pi OS with GUI but no Thonny, Geany, Scratch, etc). You could also try your hand at doing a lite install with no GUI at all. I don't think you need a GUI for MotionEye. It does all the work in the background and outputs a web UI.
I used the Raspberry Pi Imager to pull a lite version of Raspbian Bookworm plus a few basic parameters (first user, wifi).
Then tried to follow RPi-Cam-Web-Interface very verbose page, but hit a pothole on the first try.
In raspi-config, the 3 Interface Options menu doesn't contain anything related to the camera. In fact, camera support is nowhere to be found.
In fact, even after pulling the web GUI, there's no image.
From the CLI, the start.sh gives off error:
raspimjpeg: error while loading shared libraries: libmmal_core.so: cannot open shared object file: No such file or directory
I may now start all over again with MotionEye…
Statistics: Posted by Cubytus — Wed Nov 27, 2024 5:12 pm