Allow for writing to sdcard AND nfs share

[famewolf]

There are advantages to having a sdcard. If the power goes out or wifi drops a simple phone battery pack can keep your cam recording for HOURS. When my router rebooted at 4am 3 of the 4 cams I have stopped recording because the nfs share became unavailable and never recovered till I rebooted them at 9:30am. The same thing occured when the raspberry pi I have that owns the nfs share had to be rebooted. It does not seem like it would be complicated to write to both places using that one minute mp4 file and even use rsync to grab video missed when the nfs was unavailable FROM the sdcard. This code could turn these cheap camera's into a top notch security system simply by adding a raspberry pi, cheap hard drive dock and a couple of hard drives so you could rotate them monthly (giving you access to 2 months of footage).

[famewolf]

Or as an alternative make the nfs mount optional and configurable via the config.inc file while retaining the other features such as auto reboot etc.

[gtxaspec]

+1 for this, having local storage as a backup sounds like a good benefit.

Right now we mount the nfs share where the sdcard is normally mounted.

mount the SD card elsewhere, keep the nfs mount, copy the temp file to both locations?

hmm

[famewolf]

As an additional comment I added a "sleep 60" right after the sleep 3 and before the reboot in the logic that handles stale nfs handles in mount_nfs.sh....this gives time for a rebooting router or pi to come back up BEFORE the camera's reboot. It does not seem to deal well when it comes up BEFORE the nfs is back. Additional logic is probably needed to check periodically.

Having the sd card mounted also gives the user a place to store files and config for example if they wanted to run bftpd using the custom script option in the config file.

[HclX]

Due to the current design sd card and nfs share are mutually exclusive. I'm working on a change to make it possible to still mount sd card with nfs share mounted, but you can only record to one location.

[famewolf]

I'm ok with only writing to one location but couldn't a reoccuring copy runnign similar to the auto_reboot script copy the 1 minute mp4 file every minute from 1 to the other? I'd say writing to sdcard if present would be safest due to issues like power failure or the nfs server dropping due to either it rebooting or poor wifi/storms. An rsync or similar could bring them into sync every xx minutes.

[endertable]

Famewolf, what I would do is let the iCamera write to SD card and I would run a background script that automatically copies new files from SD card to NFS (if NFS is available). Upon reboot or NFS remount the script should write any missing vids to NFS. Advantages to this are:

1. SD card is a sure thing (until it gets corrupted). iCamera only writes complete .mp4 files to SD card so you know you
   are getting the complete minute
2. Script can precheck if NFS is mounted before it tries to write
3. Script can update NFS share with missing files once cam gets reconnected
4. You can have your script text you (or whatever notifications you may have on your server) when NFS goes down or if SD card
   gets corrupted and not getting new files written to it, etc., etc.

[gszakacs]

@famewolf:
Did you by any chance implement the ftp based file transfer ? I had serious reliability issues with NFS and FTP seems far better but I ran into a few issues:
The custom script is not starting the btftpd automatically. I have to telnet in the camera to manually start the ftp server.
Also a js or python script that automatically downloads the video files from the camera would be great.
I found that the bftpd and bftpd.conf files in https://github.com/Dafang-Hacks work well.
Thanks

[famewolf]

I have all the cam's going to a 6TB hard drive on a raspberry pi. After I implemented a change on the PI to make it "re-activate" the connection when the pi gets rebooted it's been rock solid. It was a command to refresh a stale nfs connection..trying to remember where I ended up putting it. I created the below as /etc/init.d/nfsmount. It first removes and then re-exports the nfs path which causes the camera to update it's side. # Description: .. ### END INIT INFO # If you want a command to always run, put it here mount /mnt/nfsshare exportfs -ua # cat /proc/fs/nfs/exports sleep 2s exportfs -a exit 0

…

On May 21 2021, at 2:39 pm, gszakacs ***@***.***> wrote: @famewolf (https://github.com/famewolf): Did you by any chance implement the ftp based file transfer ? I had serious reliability issues with NFS and FTP seems far better but I ran into a few issues: The custom script is not starting the btftpd automatically. I have to telnet in the camera to manually start the ftp server. Also a js or python script that automatically downloads the video files from the camera would be great. I found that the bftpd and bftpd.conf files in https://github.com/Dafang-Hacks work well. Thanks — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub (#68 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/ABCY74D7BZ7Q6WV4PZBXYPLTO2SG3ANCNFSM4VRHAN2A).

[BiatuAutMiahn]

For the v2 I have dafang hacks installed, along with entware so that I can run openvpn directly to my google compute node, and on that I run zoneminder. Zoneminder will then archive events after disk usages reach a threshold to a folder for rclone to move to unlimited Gsuite google drive. Personally I think it's very unreliable in terms of quality and stability, however the upside is that when it is running optimally, nothing is missed. Ie, someone with a good plan and organization could pull off breaking and entering and snatch and grab in under a minute. Having taken the hardware that stores the records or even the router per say...your SOL. Recording by means of real-time stream to cloud service ensure you get most if not all frames.

When I got the v3 and realized the pros over the v2 I sacrificed the RTSP, but the every minute interval is a problem even if we can't help it. Even more of a concern is that I have an AutoPi in my car with a v3 on the dash with an nfs server, and I attempted to manually transfer the records off of the nfs share. This was a nightmare as every 2 seconds or so the Pi completely locks up and all I/O locks up. After pulling the sdcard and manually transfer I find heavy corruption, and the most affected area was the nfs mount with multiple days of video missing. The AutoPi triggers a sleep mode if the battery gets low, and will even kill the pi if the battery dips far enough. Not to mention the sleep timers for various conditions.

Anyway to the point, the NFS method is a nice hack but unreliable for a few reasons on my part alone, imo it would be better to record directly to sdcard, if it exists (fallback to just NFS sdcard mode if non-exists) and run a daemon in background to copy records as they close or after the increment is created to the NFS share.

I started off talking about entware with dafang hacks on a v2. I humored the thought to do a local recording and with using a python script I'd manage the recordings via transfer to the GCP node, and a rotation of like 7 days or so. that way storage doesn't fill up and make the storage host unusable.