dexterash

Quickly put: HDCVI is Analogue, which means no compression, but also easy prone to interferences and signal degradation over distance. Also, there are multiple Analog->Digital->Analog conversions, that might interfere with image quality. IP is digital all the way, from sensor to (almost) display. It's like comparing standard PAL/NTSC television with DVB-C/DVB-T quality.

Of course! It's a multi-user, multi-tasking device. The NVR doesn't lock, just the account get's locked after multiple unsuccessful logins. I don't think it's a SmartPSS bug. Maybe a configuration problem or something else...

Then if I know someone's P2P SN or port forwarding ipaddress.. I can log in with "admin" name using any password and he would be locked for 30 minutes enough to effectively disable his security and remote monitoring. So if the robbers know your unit serial number (P2P) or ip, then you are vulnerable. Dont you agree? Is there no way around this? This defeats the purpose of remote monitoring. You have local storage - DVR or NVR. Even if you lock the account, the recordings or the whole functionality of the system will not be affected. Also, there are ways to combat brute force attacks: for example, changing the default port forwarded. And, as I stated before, remote monitoring can be done with any other account - btw, it's a bad practice to use admin to remote monitor. Also, the admin user (if I do remember well) can be locked out from network login. There are several ways to mitigate any or all of the problems that do arise in these situations or some other particular situations.

Will lock remote access only for "admin" account, not for all accounts.

You cannot disable this feature, specifically designed to stop brute-force attacks. If you design very well your system and you use a "special" account - for example, a very uncommon username - there will be no problems in remote accessing the devices.

I doubt you'll find a good NVR that's non-ACTi. Your best shot would be a PC + NVR Software. If I were you, I would return the cameras too - they are kind of old and MPEG4 compression (non-H.264) requires a lot of space&speed/bandwidth - and get whole solution from a single manufacturer.

Check this: http://www.dahuasecurity.com/spartner-2.html It's not a simple compression/codec problem, but rather the protocol used to communicate with the camera besides the video encoding. Also, not all manufacturers implement the same way the codec. There should be "something" that replicates the same settings used to encode in the NVR/decoder.There are lots of other facts, like Motion Detection, Playback, Alarms etc.

Get a dedicated NVR - better, faster, more secure, less prone to errors.

I wouldn't be that sure! Depends on SoCs used.

How are the cameras connected to the NVR?

What protocol is used by the NVR to connect to the cameras?

What protocol are you using? Is the QVIS a DAHUA rebrand?

Box: http://www.dahuasecurity.com/products/ipc-hf81200e-792.html actually this model, if I do rememeber well.

The one that we saw/tested was using H.264. We managed to decode it with SmartPSS, but there was some lag. DAHUA stated that they are developing a better SmartPSS version and a dedicated 4K NVR.

You're welcomed. It's a DAHUA product and we haven't encounter this kind of unusual behaviour from them. By the way, setup the DNS servers, NTP server and DST so it will automatically update the hour - no more 2am reboots when it's 1pm.

Or you could get a dedicated rackable 1U-2U NVR, that can do more than any PC and handle storage/recording to 4-8HDDs. Besides that, DAHUA's ONVIF implementation in NVRs is kind of good, stable, mature and it works well with most of the ONVIF certified cameras. Less power consumption, almost same price of the hardware of a PC, no software fees, better results and way more performance in FullHD or upper decoding/recording.

Please understand that this is not a DVR/NVR issue, rather a bad motion detection signaling implementation in the camera. I suggest you change the camera with a DAHUA one or a true ONVIF Certified one, that comes from a better manufacturer.

Only at bootup - it's self calibrating. In normal usage, no, there shouldn't be any "clicking" noise.

Maybe maintenance reboot enabled?

PM with all the details of the implementation and we'll come up with a solution, either hardware or software.

Why not ask for support directly from DAHUA or from the seller of your card?

In IP Solutions, Motion Detection and signaling is done by the camera, not the DVR. Also, check the PTZ protocol selected for controlling that camera. P.S. Is it ONVIF certified? http://www.onvif.org/FindaProduct/ProfileProducts.aspx

1. Loudness depends on specific model, not brand. But 90% of them use fans. Also, HDD is kind of loud. 3. HDCVI is not IP over COAX. HDCVI is Analog HD (over COAX or UTP). If your current setup is ok, then there shouldn't be any problems. Though, DAHUA's MEGAPIXEL HDCVI Image Quality is lower than DAHUA MEGAPIXEL IP Quality.

I doubt you will find a solution, since: -the keyboard must know a special protocol to connect to the NVR via RS485 and control it -the NVR must accept control from an external keyboard via RS485 -the NVR must know the protocol of the Speed Camera and control it via IP Since none of these are true for you, I don't think you have any solution.

Taking a deep breath and: There is a tricky difference between bitrate(which refers to stream quality/compression/blah blah) and bandwidth. Yes, it is a big difference, especially in motion-full scenes. If you want to understand more, read about the H.264 and how it sends frames that are only consisted of differences from previous frames(I can't find a simple way to explain it:). Not BDray, but: Swicth it to 1080p, let youtube reload, pause on a frame and observe the details. DAHUA's website has some flaws and, sometimes, it's not even updated. We updata and test a lot(I mean, a lot ) of DAHUA products and usually the specs are better than those initial specs on website(yes, descriptions on website are initial specs). I use it too. BullsHomething 2. Yes, the stream is continous. Yes, the NVR does the record. BUT the NVR starts the recording when a motion event is sent from the camera. Thus said, besides the Video Stream there is a stream of METADATA/CONTROL from the camera to the NVR and vice-versa. This is where the "cheap" comes from. The manufacturer only manufacturers, it's the resellers job to support, market and resell the product. That is why is very important to chose a good reseller (and one agreed by DAHUA). Max Bitrate is lowered when the FPS is lowered. Yes, your examples are close to reality.