dexterash

1. Yes 2. Depends on network topology and devices used. There are cameras that connect & stream and there are equipments that connect to cameras. NVRs are in the 2nd category. NASes ar in the 1st category. 3. Usually MD is done by the IP Camera, not the NVR. The camera "signals" the NVR. I know, this is opposite from standard DVR operation. 4. Depends. There is some standardization, but not with the best implementation. Proprietary protocol is always preferred. Anyway, look for/at ONVIF and PSIA. 5. Usually, depends on the NVR. Cheers!

Something's fishy around there. DVR is one, NVR6000 is another thing and PSS clients are another one thing... If you want the job done right, PM me with the details and the requirements. NVR6000 has local decoding capabilites so no others PCs/decoding clients are required unless we are talking about a distributed system...

Are you sure your PC is able to handle 50 FullHD streams? What is the CPU load?

Cameras are non-DAHUA? How is the NVR connected? PSS running on what?

Huh? What does arping have to do with checking tcp ports' response? Or the MAC? So the camera doesn't even respond to ping? Check the hardware/network. The network part of the cameras starts way before any other server/service. Even with a broken firmware, 50% of the cameras are able to respond to ping requests. Something's fishy around there.

Ok, define "hang". Ping requests? Webserver alive(port 80)? Proprietary data server (port 37777) alive? ConfigTool sees them alive?

Ok, thay can hang from some reasons, but I've never seen one device that will not come back alive. The software/hardware combination does not allow this. So, either the camera come backs but at a point it hangs and you never see it online (and enters a reboot loop) or the hardware has a problem. All the software in these cameras is monitored by the hardware. If the software hangs, the hardware reboots the cameras.

Our wiping involved desoldering the flash(NAND ic), wiping it through a flash eraser and rewriting the whole flash. We tried at cameras' Linux level with no luck (most partitions are read-only), so no telnet/root access can help and the commands/utilities available are very limited. And yes, newest firmwares have dynamic root passwords (due to publicly available root password a patch was created and implemented).

As I stated before, Synology sends some "setup" requests to the cameras, before the actual streaming begins. In these requests the client tries to change the servers' streaming parameters so it can match Synology's decoding power/decoding library/decoding client. So the "view" also implies some setup/parameter changes in cameras' RTSP server. And yes, they are still rebooting. We had a similar case where a Synology NAS screwed the voice communication of the cameras(in the setup portion of the RTSP protocol). We had to completely wipe the flash and rewrite the firmware. After that, all went ok - but we recommended not to use Synology's client anymore. And the system has worked flawlessly since that.

Where's the logic? The system worked (in a way), then you upgraded (for some reason) a part of the system, the whole system failed to work after the upgrade, and you are still blaming the rest of the components, but not the one that you changed/upgrade?! No, there is no cron in DAHUA(lacks from the Linux). The Synology just f*cks servers implemented in cameras due to poor implementation of client commands. BTW, have you talked with Synology about this?

With the latest firmware that you can get for the cameras.

Reset the cameras to defaults. If that doesn't fix, reflash the cameras.

Best/simple solution: use an Android box and the dedicated Android app.

You should try, but hardly will solve your problem.

It's simple: Synology cannot connect using the standard, proprietary protocol that DAHUA products use to communicate between them (port 37777), so it uses a general RTSP protocol(as defined per ONVIF standard) that, usually, relies on opensource live555 library. Live555 library is known to be buggy when decoding RTSP streams, encoded by different RTSP servers. When setting up the RTSP connection, the client issues different commands as per protocol specifications, but some of these commands might be out of protocol specs or might be device-dependent. Actually the RTP/RTCP part of that protocol might pose those problems. So, sometimes it works ok, sometimes it doesn't. To be honest, seems more like a lucky dice throw.

2100 is almost 2 years old and is already obsolete. 4100 is about 6-8 months old. In two years Synology had the time to fix any bugs that appear when connecting to that camera. 4100 might be a little bit too new. I'm not here to argue, just wanted to try to point you in some directions to find the culprit.

If you disconnect the Synology from the IPC and the camera still reboots, then it's a problem with the camera. But if it only reboots when Synology connects to it, then the problem is in the client software that might issue random commands that could make the camera reboot. We've been working for over 5 years with DAHUA products. There are no such bugs that could make the hardware reboot, unless either it's a hardware error (temperature, bad RAM, etc) or something that comes from an external source (like a 3rd party client software). Ok, forgot the "bad install" error .

You're not the first, nor the last person that will have problem with software NVRs (let's call them NVRs, although they are NAS devices). It's been 6 months and you still are chasing solutions for a problem that can be solved in a jiffy, with a simple solution. Temporarly, you could get a NVR for a week for testing purposes to be sure that the problem is in the Synology software.

Get a true NVR(preferably by DAHUA) and all your troubles will go away.

You can always setup presets on them and let them do your work. Also, High Speed Domes will move in less than a second from one view to another.

My 2nd tip: wire&connect cameras in order and never connect more than one "new/out-of-box" camera at the same time.

I'm not very familiar with HIK's SADP, but DAHUA's Config Tool should help you. That's all you need.

admin/admin Admin account seems to be locked - you've tried more than 3 bad combinations in a 30 minutes timeframe. Reboot the camera and retry admin/admin.

The technology is getting cheaper. Same as what happened with smartphones, tablets, SmartTVs etc.

8192 just for Main Stream. Extra stream needs some bandwidth too and the NVR connects both to extra and main.