joshuaad

That's the first thing I did. Here's his answer: "Actually nothing and it will delay the DVR from recording if it is set for motion on that channel. It's supposed to act as a noise reduction but does have an affect on the motion settings. If you were to set it to 5 and motion came into that channel, you would see a delay in recording or may not record at all." I was hoping it was a filter and that I could eliminate the sunshine/cloud effect. I've got a channel with it set to 2 to see if it helps. The range is from 0 to 600 seconds. I can't imagine filtering for 10 minutes! Tom You would never filter for 10 minutes so the answer is not accurate. I was researching this setting as well and from the IC Realtime forum they said it was designed to minimize the number of motion detection event within a given time period (in case there was too many triggered events for a given camera). So 5 seconds is the minimum and up to 10 minutes. Whatever setting value is chosen is the amount of time during which only one motion detection even will be allowed.

I am having the same issue myself, mostly in the early morning hours using a Dahua OEM NVR and some IP cameras from a different source. I have given up on the internal settings of the NVR as they seem to affect little other than have motion detection enabled. So at this time the camera's internal settings is what I'm playing with. No success just yet (I keep lowering the sensitivity (down to 40 or 35) and the threshold setting is now up to 70 and still lots of recording on the IP cameras during the early hours when the light is changing more dramatically. There is a night setting for motion detection in the cameras so I am using it (5:30 AM to 7:30 AM). It's pretty tedious as motion detection is key for user friendliness and a quick check on activities. No issues on the analog side either.

Thanks ssnapier. What confuses me, and of course I am not with the client in Germany to double check what she's reporting, is that only one of the DVR's (16 CH, older unit) is displaying the issue. If the ISP was at fault, would it not affect both DVR's? Running a trace route (from my local USA office) to the static IP shows a number of packet losses (using iOS Nice Trace app). I have never done that before two I'm not sure what to do with the results. Alan

Thanks Don. I'll check on the firmware. The DVR is at least 5 years old, maybe more. I'll post my findings if I can figure out a fix. Alan

Thanks for your help, Don. I believe the error message is either "failure" or "System failed". It either comes up right away or after a few minutes. It definitely is not a login failure. So I'll say it's a time out issue, but why is it only happening on the 16CH DVR. Would a newer DVR (like the 8CH one, installed in the last year) be likely to work better? I certainly don't want to go through the process and expense only to get the same result. I do trust IC Realtime's tech support but sometimes field experience can come up with solutions that tech support doesn't think of. I'm just trying to do my due diligence for the client. So this is a little bit of a mystery so far. Alan

Hi, I am looking for suggestions on a specific issue which I have not been able to resolve so far. I have German clients in Scottsdale Arizona that own a ranch where we have 2 analog security DVR's from IC Realtime: 1 has 16CH , 2 has 8 CH (I added the second one). When in the US, there are no issues connecting via the iPad app (ICRSS Pro) to both DVR's. But from Germany, the client has been reporting repeated fails from DVR 1 (16 CH) and I am not sure why. I have contacted tech support for IC Realtime and they also had no problems connection from Florida. They told me it had something to do with packet loss and the various hops the signal had to make from her location to AZ. It still seems to me that it should be able to work especially given the fact that the newer 8CH DVR seems to be working fine all the time from what I'm told. Ports have been properly forwarded and we have a static IP here in AZ. Any suggestions would be greatly appreciated. Alan