aster1x

@just_having_fun I agree with your observations. I repeated your steps and I confirm them. However the time it takes for the NVR to update the camera clock is not a constant period. It may be seconds, it may be a few minutes. So even if the time zone of the camera is set to the wrong time zone, as long as the camera time is set to manual, the camera will be synchronised to the NVR clock, although the time zone will be wrong. Now I can confidently conclude that the conflict comes when the camera is set to take the time from an NTP server. It seems that the NVR tries to update the camera clock, and at some time the camera will try to update its clock from the NTP server. If the two clocks are the same then there will be no apparent problem. If on the other hand the NTP clock differs form the NVR clock then the camera will keep the last clock update irrespectively where it came from. I believe the above clarifies the rules of setting the clocks between camera and NVR (at least to my mind!!). Thanks to all who contributed to this troubleshooting.

@just_having_fun Have you tried to let the NVR do the switching of the DST automatically? This is what screws my camera and NVR clock synchronisation. According to my experimentation the camera and the NVR can have different clocks.

To make matters even ... worse, it is possible to have both at the camera and the NVR the same settings for time zone, NTP, and DST settings and the NVR can have one time at the configuration panel, the camera can have another time and the video recorded at the NVR to display the camera time and not the NVR time!!!!! So who is updating who, the NVR updates the camera or the other way round? OR they are independent? Mind you that there is no way to define at the camera configuration that the camera is connected at the NVR. Only the NVR knows at which IP the camera is connected to pull the video stream. So how can the camera update an NVR if the camera does not know the NVR existence and its IP? Unless when the NVR pulls the video stream from the camera, the NVR updates an internal setting that identifies the NVR to the camera. However this is a hypothesis and not a fact. Does any one have any more specific and official knowledge of the time synchronisation between the cameras and the NVR?

In the HIK cameras there is no explicit option to synchronise its time from the NVR or from an NTP. In the HIK cameras we MUST select some time zone. It is not possible to leave the time zone null (empty). The NTP settings can not be disabled unless if we do not define any NTP server then it is implied that the NTP service will not update from any NTP server. However does this mean that the camera will then update its clock from the NVR? Is the above true irrespectively of whether the camera is connected to the NVR internal PoE switch OR the LAN switch (i.e. externally to the NVR?)? I had set proper definitions of time zone, NTP server and DST on both the camera and the NVR (the camera was connected to the internal PoE switch of the NVR). All was working OK until the DST switch time. The NVR updated and synchronised correctly, but the camera went off by a whole hour (equal to my DST bias time). Could this be due to the DST setting of the camera? It is not very clear how the time clock synchronisation works between the camera, the NVR and any NTP server.

If you do this (change the camera IP to 192.168.1.XXX) then you must also change the IP of the internal gateway of PoE switch IN THE NVR to something like 192.168.1.100. If you do not change it, then the NVR itself will not be able to access the camera. In network terms what you are trying to do is feasible. However, I do not know if the HIK NVR will recognise this IP setting for the PoE switch (I am not convinced of the software development quality of HIK Vision). If it does not, then set the NVR PoE switch gateway back to 192.168.254.1 and set the camera to 192.168.254.2 and so on. Tell us the results of your experiments.

YES. In general, if you have a simple PC with no other routers in the LAN and with no specific routing rules applied in the PC, you can only access IPs in the same range as the PC IP, i.e. if your PC has an IP of the form 192.168.1.XXX then you can access only devices with IP in the range 192.168.1.XXX where XXX=1-255. You cannot access IPs of the range 192.168.254.YYY . Also do not forget that if you connect the camera directly to a switch you must provide power to it somehow, either 12V through the pigtail OR 48V from the PoE switch through the LAN cable.

If your PC has an IP of the form 192.168.1.XXX then you can only access the NVR web interface at 192.168.1.YYY (the NVR lan port IP). The NVR PoE switch has an IP 192.168.254.1 which is internal only for the NVR. If you connect your PC to the NVR PoE switch (not the NVR LAN port) then you must set your PC IP to something like 192.168.254.ZZZ where ZZZ is anything larger than 16. In this way you will be able to access the cameras connected to the NVR PoE switch since each camera is assigned the IP 192.168.254.AAA where AAA>=2. If you have NVR firmware 2.3.9 or greater then you can enable the Virtual host feature that allows you to access the cameras interface through a port of the NVR (like 192.168.1.YYY:65001) instead of the camera IP. There are many threads in this and other forums that explain the various ways of accessing the camera's interface with and without the Virtual Host feature.

They should sychronise the functionality between the NVR native interface and the NVR web interface. For example: 1. The events logged in the NVR have more detailed description in the native NVR than in the web interface. 2. The EZcloud functionality appears in the NVR native interface but not in the web interface. 3. Validating the proper functionality of the various settings (especially in the network) should appear on both native and web interface. 4. The functioning of the DDNS and the email should be made more robust. As of now there are cases where both of these functions fail to operate and there is no notification of any sort to the operator. 5. The motion detection mechanism fails many times rendering it unreliable. In general HIK Vision must pay more attention to the reliability of their software and proper documentation. No commercial distributor will ever do this job for them. In fact it is the users that are doing this job by experimenting in this (and other) forums.

I am afraid I will dissapoint you. I have the HIK 7604NI-SEP NVR and there is no snapshot functionality of any kind. I also have the same problems with a 2cd2332 camera wih firmware 5.1.6. Now if by NVR you mean a PC with software like Blue Iris then I do not have any expereince on that solution. In general the HIK VIsion firmware for cameras and NVRs is very flaky and inconsistent.

Is there a way, a command or something else, in order to find which CMOS sensor is used in HIK Vision cameras?

Indeed the NVR firmware version 3.0.8 has disappeared from the European portal (just like the camera firmware 5.1.6???) I wonder why. In any case this is not a serious and professional attitude from an international company of this statue. In fact I just found that you can upload, copy and delete any file in the USA FTP site!!!!. Who is the master administrator of this FTP site? All of us?? Anyone can upload whatever they like?

Are there any functional differences with version 2.3.9?

Do you produce surveillance cameras? What do you mean by " ... more details.."? What sensors do you use do get better image quality? Please provide us with more info.

I have tried HIK DDNS but I have not been succesfull. In the HIK-online.com site, I have acreated an account, I have added manually the serial of my NVR but in the device status, the HIK DDNS reports that the device is offline and displays a completely wrong IP. I am absolutely certain that I do not have a network, or router or NAT problem because if I use the domain name that my router updates automatically at the NOIP DDNS provider, I can succesfully access from the WAN my NVR. I use the DDNS updater of my NVR to update another domain in my NOIP account which of course resolves to the same WAN IP as the domain name updated by my router. The NVR updating in the NOIP provider has worked in the past but for some reason it does not work anymore even if I reboot the NVR. Therefore I conclude that my NVR DDNS updater functionality is unstable.

HIK DDNS works very well on it's own I do not understand why u use together with no-ip I use only NOIP DDNS provider. I do not use NOIP in conjuction with another DDNS provider. I prefer the NOIP compared to other DDNS providers.

For the past one month of operating the HIK 7604NI-SEP NVR with firmware 2.3.9 beta, the DDNS function does not operate reliably. Sometimes it updates the NOIP provider, sometimes it does not. Is there anyone with a reliable operation of the DDNS function?

I suggest that you always check the frame rate and bitrate of the recorded video with Media Player Classic (or VLC or any player that displays the technical characteristics of the video). Also do not trust what the settings of the interface say. As an example, in firmware 5.0.2 with a 3Mpixels 2CD2332 camera the frame rate was set at 25fps and the final recorded video was only 12fps. It was a firmware disfunctionality (the polite expression for .... bug) and it is very well documented in he forums. This ... disfunctionality was fixed in version 5.1.0 (or later). However an inexperienced eye could not see the difference in the playback view of the NVR interface. Also 5Mpixels at 20fps and at say >5Mbps requires a lot of processing power. How certain are you, that the camera CPU can handle it? One or more of the above parameters is reduced automatically without notification from the camera in order to handle properly the video sream. One hidden parameter that is almost used to sacrifice quality in order to manage the video stream is the compression factor in the H264 algorithm. The effects of high lossy compression are dramatic in visual quality. Conclusion: Always take the settings of the interface and in general the chinese software and specifications with a pinch of salt and verify the final result with third party tools.

OK now I understand how you do it. Here are my reasons for using the internal PoE switch of the NVR: 1. One less equipment (switch) thus cheaper 2. Less cables, and smaller footprint 3. When cameras are connected to the internal PoE of the NVR they are more secured (i.e. not accesible from the WAN side easily especially if you disable the Virtual Host feature of the NVR firmware 2.3.9. 4. (The most important reason) The camera traffic does not appear or broadcasted in my lan which I use for very large file transfers and therefore my LAN switch is not taxed with additional traffic switching and processing.

OK I get it. The bandwidth calculator is a theoretical calculation tool. In my setup (7604NI-SEP + 2CD2332) the camera is connected to the NVR PoE switch, it has an IP 192.168.254.2 and the NVR LAN IP is 192.168.1.XXX. In this configuration the cameras belong to a different subnet and he SADP canot see them. How have you managed to see the cameras with SADP tool?? Have you created a loop back from the NVR PoE switch to the main LAN?

I also have doubts about the proper functioning of motion detection. I have several examples where specific motion events hae no been detected. Thankfully I had specified the whole system to have enough bandwidth and storage for continuous recording. So now I am operating on continuous recording 24x7 to be safe. The annoying thing is that when the disks get filled up and the overwrite of the oldest recording begins the available free space on the disks is always 0, which is right but obviously meaningless after the first overwrite. I also have two disks for redundancy. I discovered that the video is never lost irrespectively which disks disappeares for whatever reason but the log is only written in the first disk and it is not recorded mirrored in the second disk.

At which software or interface do you see your attached pictures and under which menu?

Now I'm really confused. Well I do not blame you catseyenu!!! This is the reason I was enquiring how to know and display constantly on the screen the CPU load of the camera AND the camera. All explanantions given by fellow members make sense under certain cases. Only if we know the camera and NVR CPU loads, we will be able to understand who is doing what and when.

Same as what I originally posted, but with IE it does not work, gives in an error "Windows cannot find....". With Firefox it asks me if I really want to log in, how annoying is that. Not as friendly as the onvif/snapshot in older firmware versions. It does work with the curl command, directed the output to a jpg file on my desktop and it appeared there. What are you using this command in that works for you? Don't get me wrong, I'm happy it works with curl because then I can script it if I had to. Ideally if I can find someone to help me that's a C programmer, I can used curl to maybe extract images from the camera, say 4-5 times per second, pass them to openalpr to create a cheap (free) LPR solution. Here is something interesting. If the camera firmware version is 5.1.6 the snapshot script executes properly from the WAN (internet) without any user:password requirement. That is a serious security hole especially for those with static WAN IP. I tested it with IE11 and chrome. Whereas in version 5.2.0 according to @catseyenu at least the user:password credentials are validated. It seems that in version 5.2.0 they fixed this security hole.

That is the best solution when one has to update mulitple host names for the same network. Therefore you can have any number of DDNS updaters updating any number of host names in any number of DDNS providers. I would like also to suggest the use of DNS-omatic (https://www.dnsomatic.com/) service that allows one DDNS updater (say the router) to update one DNS-Omatic account and then DNS-Omatic undertakes to update all host names to DDNS providers that are registered in this DNS-Omatic account. The usefullness is that if the number of the DDNS updating capable devices is less than the number of host names that you must update, then DNS-Omatic is the only solution. Check this http://blog.pcfreak.de/2010/08/30/mehrere-dyndnsopendns-accounts-mit-fritzbox-aktualisieren/ for a detailed explanantion how to setup the router (or any other DDNS updater that allows a user defined DDNS definition).

Ok lets clear a few things about DDNS. 1. You are correct that the ADSL router (usually) has a functioning DDNS service with your prefered DDNS provider (hopefully the few remaining free DDNS providers like no-ip) that updates the DDNS provider automatically with your public (WAN) IP whenever it changes (usually during ADSL resyncs and reboots). 2. Although the (HIK) cameras have a DDSN service update, this service cannot be operated if the camera is connected to the intergrated PoE switch of the (HIK) NVR because the HIK NVR mayNOT allow any service outgoing from the cameras through the NVR lan port to the internet. ( I have not completed entirely the testing of the camera with proper network settings connected to the NVR). The cameras DDNS is functional if the camera is connected to the LAN switch and the recording is done either with an NVR or a PC based solution with the assumption that all devices mentioned, belong to the same sub network of the LAN like 192.168.1.XXX. 3. In the case that the cameras are connected to the NVR PoE switch OR if your ADSL router updats a DDNS provider with a specific host name for your network OR if your ADSL router DDNS is not functioning properly OR if the ADSL router does not support your prefered DDNS provider -although the HIK NVR may support it- AND you want to access the NVR with ANOTHER host name, then you need to update two host names with the same -or even different- DDNS providers. In this case the DDNS updating from the ADSL router is not sufficient, we need an additional DDNS service updating mechanism and a solution would be to use the HIK NVR to update your prefered DDNS provider with the host name of your choise. The problem is that the triggering mechanism for the DDNS updating by the ADSL router is the resyncing or rebooting and the change of the WAN IP. A computer does not have such a triggering mechanism. This is the reason why many DDNS providers provide a small software utility that runs on a computer all the time and checks and updates the DDNS at predefined intervals. Obviously any WAN IP change within the updating interval is not logged at the DDSN provider and the respective network is not accesible from teh WAN side with the preselected host name during this interval, until the the next DDNS updating. After a long time I managed to setup and function properly the DDNS of the DS-7604 with firmware 2.3.9beta. The HIK somehow understands when the ADSL router acquires a new WAN IP (for whatever reason irrelevant to the NVR) and updates the configures DDNS provider. A downside to the firmware is that it does not provide any feedback of the response from the DDSN provider. Therefore if your login credentials are not correct and there is an error returned form the DDNS provider, then you do not know it. I hope the helps to clarify a few things. EDIT: I have confirmed that the HIK NVR checks at unspecified intervals the WAN IP and updates automatically the DDNS provider wth the new WN IP.