Vivotek motion detection settings

Hello! I have two Vivotek ip8332 cameras. I've recently suspended my hunt for an NVR after I realized the cost would be more then I can handle right now. After messing around in the interface I realized these cameras can save the feeds directly to a network location, which means I can save the feeds to a folder on my Linux Samba server. This is the definition of awesome. I successfully set up full time recording without a hitch. The problem comes in with motion detection. Even with it enabled, the window mask set up, etc it won't save anything at all. I noticed a lack of decent activity in the motion detect window, despite the sensitivity being super high and the percentage parameter being very low. Even dancing in front of the cameras doesn't trigger anything. If I switch back to full recording things work great.

Has anybody had trouble setting up the onboard motion detect? For the life of me I cannot figure it out. Any insight?

So I've found a few things out that I wanted to relay back here. The onboard Vivotek motion detection that's on the web interface of the cameras themselves isn't anything I'd consider a high quality feature by any stretch of the imagination. Once you do get everything set up (I used network server, along with the video clip media as the recordings for motion detection), there's a lot of limitations that leave a lot to be desired. For example, the maximum size you can set for a motion detected clip is 4 MB. I actually thought this was sarcasm at first. 4 MB @ 1280x800/30 FPS is about 5-7 seconds at best. Sure, I can lower the FPS, but it's still far from optimal. On top of that, there's a break in between each clip where the camera has to process end of clip 1, beginning of clip 2, etc. I have to wonder if the 4 MB limitation is a result of the break time, because the camera needs to process the feeds it's seeing. As a result, if you dance around in front of your camera for 30 seconds, you're likely to see:

5 seconds of footage

5-8 seconds of downtime while the camera crunches the feed

5 seconds of footage

5-8 seconds of downtime while the camera crunches the feed

Some people may only be after catching mere glimpses of motion detect, but I don't consider this to be all that usable for my uses since a single feed is A) far too short and B) the downtime in between each feed while the camera does the processing is too significant. There are other media options though, where I can utilize jpg screenshots instead of actual video feed. This too is limited at 7 shots per detect, but I have a feeling it would be significantly better in terms of usability vs the video clip recordings. I, however, wanted video clip recordings, so I didn't even explore this option. This is where the tech I was speaking to (who was crazy awesome to deal with... love Vivotek support) said this is one area where a dedicated NVR would help out, since a dedicated box of course comes packaged with the CPU power to handle things like this (which of course makes total sense). I informed him that the Vivotek NVR's are quite a bit out of my price range (I think they start at 800 or 900), and on top of that, until Vivotek makes their ST7501 NVR software for Linux, I won't be using it. I hate to sound unreasonable or stubborn about utilizing something other than Linux software, but all of my services I use work on Linux out of a single box, which means in order to use the Vivotek NVR software, I would need to set up a secondary box JUST for NVR purposes, which requires a whole separate box, Windows license, etc. No thanks.

Instead I decided to just do full time recording, which works absolutely brilliantly. It uses significantly less processing power, so pulling 30 FPS H264 @ 1280x800 is extremely fluid. Two cameras on the LAN using my Raspberry Pi as the Samba file server, it barely sees 1.5 MB/s with both cams running full bore with excellent quality settings... all the while the Rasp Pi's CPU usage is all but idle. The cameras at least name the files based on date, time, etc, which makes identifying the feeds easy. There are limitations on the 247 recordings too, but it's limited to 10 minutes or 300 MB, whichever comes first. Granted, running continual streams like this around the clock is going to take a toll on disk space, but once I drop it to 10 or 15 FPS I should be able to get quite a few days out of my current 500GB hard drive. Not to mention, I'd rather spend 300 bucks on massive hard drives to use with full time recording on a very efficient box like the Rasp Pi versus spending 800 on a dedicated box powerful enough to handle motion detect. Plus I'm finding the other uses I had for my regular Linux server is working fine on the same Rasp Pi, so I just may be able to utilize my Rasp Pi for all of my server uses and keep the main server offline. This would be great from a power efficiency standpoint... but there again, all of this is just my 2c.

At the end of the day, I'd love to have motion detection, but the more that I see what kind of processing power it takes, coupled with the efficiency I currently have of the cameras doing 247 recording and the Pi being my server, I have to say I'm quite happy with this setup.

Not to beat a dead horse, or an old thread, but there's still a benefit of the motion sensor option - just ignore the (broken?) video feeds it creates and just use the events as timestamps.

In this way you stream 24/7 video to your server, and the motion detection alerts serve as pointers to tell you which video files might be of interest. Saves scanning through a multitude of 10-minute video files to see what transpired.