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 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.