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.

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.

What do you mean " ... flash drive was compatible"? The NVR recognised the USB memory stick, it started reading the firmware file and approximately at 50% progress it gave the error " Upgrading failed .... ". From the previous post I am suspecting that it may not be possible to jump some firmware versions. I will try the 2.3.8 and if successfull then I will try the 2.3.9 beta.

I have the same experience. I have a HIK DS-7604NI-SEP with serial number that contains the characters BBRR in the middle of the string. I tried to upgrade from firmware 2.3.7 build 131112 to the firmware 2.3.8 build 140513 from the USA HIK ftp site and it failed half way through with the message "Upgrading failed, no enough flash memory". It also failed when I tried the USA firmware 2.3.7 build 140122. Careful these are the 5 versions of 2.3.7 available in total sorted by date. Version 2.3.7 build 131112 from the European portal most commonly ecountered in many HIK 760X NVRs (file size 13.677.413 Version 2.3.7 build 140122 from the USA HIK ftp site (file size 14.831.804) Version 2.3.7 build 140327 from the European portal (file size 15.461.588) Version 2.3.7 build 140411 from the European portal (file size 15.456.928) Version 2.3.7 build 140609 from the European portal (file size 14.270.397) Then the following firmware versions followed (file size 14.830.554) Version 2.3.8 build 140513 from the USA HIK ftp site (file size 14.209.552) Version 2.3.9 build 140704 beta from the USA HIK ftp site If anyone else has additional information or know anything better, please advise. I only managed to upgrade with the latest European build 140609. I have NOT tried upgrading to 2.3.9 build 140704 beta yet. What is this flash memory? Why smaller firmwares can not fit in the flash memory and the larger firmwares are acceptable and only from the European portal? Is there a connection with the 4 characters in the serial in the same way as the region in the cameras firmwares? I urge anyone who has upgraded succesfully this NVR to inform us which model they have upgraded, the characters in the serial number and from which version firmware they upgraded to which version taking into account the above information of the firmware history.

Can you see in the NVR web interface the functionality which is under the section "Events" of the firmware later than 5.1.2 version such as Face detection, Traversing Virtual plane, Intrusion detection, scene change detection? In other words teh questions are: 1. which camera version do you have 2. What are the 4 characters in the middle of your serial of the NVR and 3. if you can see and control all the camera functionality from within the NVR interface with firmware 2.3.8.

Of course, this I understand. You said some power supplies were under powered (had issues?). Which PS and is there any discussion links about this? I have not seen in the popular forums discussions about underated power supplies integrated in the NVRs with PoE switches. However I have discussed with many technicians and most of them do not understand that the sum of power consuption of all cameras connected to NVR must be less than the power capability of the PoE switch. Additionally since the power supplies are the most expensive component in any device (even the computers), the power quality varies with the design, the quality of the components, the manufacturing process and the quality control. Not all power supplies are made the same. I wonder why I have seen in many forums recommending to have an external PoE switch with a particular Zyxel model being very popular. Specifically TomsHardware, a popular computer forum, is publishing frequently computer power supplies reviews of many computer power supplies. It is interesting that some of them sol in many stores are blown after a few hours of operation. Other than that, I have not seen specific NVR power supply reviews.

What make and model is your NVR? In which menu do you see this option? Do you see the NVR interface through a web browser interface in a computer connected to the LN port of teh NVR OR do you see the NVR interface through a monitor connected to the rear side of the NVR (VGA or HDMI)?