Incorrect Time on Hikvision DS-7716NI-E4 After Power Down

[yorkie]

I have the above NVR set up for my home system, after a while of it on bench test with a few cameras connected to it. During testing I didn't notice this issue, however now a little bug has popped up.

About 2 weeks ago we had a power cut (I am yet to sort out a UPS), and so the power went out to the NVR. The power was off for 72 minutes, yet when the NVR had fully rebooted all cameras connected showed a time of exactly 30 minutes behind the correct time. More recently I had to shut down the NVR properly in order to attach an additional HDD - and on rebooting the system the time was behind by 10 minutes.

The current time settings for the unit (UK Based) are as follows:
Time Zone - GMT+0
NTP - server1.uk.pool.ntp.org
Port - 123 (have also tried 1023)
Interval - 30 min
DST Start - March Last Sunday 0100
DST End - October Last Sunday 0200
DST Bias - 60 min

As far as I'm aware, these settings are correct, and yet the time output behaves as if it has frozen from the moment the unit has shut off. I would have thought that even if this is the result of a dead CMOS battery that the time would eventually synchronise correctly after the 30-min sync interval has passed, yet even after 2 hours it stayed the same.

__

Other niggles:-
- I have a Hikvision DS-6704HUHI-K encoder connected via POE to the NVR; the time settings are the same as the NVR, yet the time shown on all the feeds of cameras connected to the encoder are 6 seconds behind the time of the LAN/POE cameras

- I have an el cheapo Sricam camera connected to POE of the NVR, and the time stubbornly remains 1 hour AHEAD of the NVR time. If I connect the camera using a patch lead to a LAN switch, the time can be set correctly but only seems to stay correct for about 10 minutes or so. On the playback timeline the activity shown is synchronised correctly with the time on the timeline itself, but the time shown on the camera feed itself is out.... I have read elsewhere that this is actually a problem with the NVR double-applying the Daylight Savings offset, but is this the case and is there any form of fix - or do I have to wait until the end of October for it to self-right?.... . I will eventually get a Hik camera there instead.

 

[alastairstevenson]

NTP - server1.uk.pool.ntp.org

That's not a valid NTP server.
Presumably you mean 1.uk.pool.ntp.org
Or suggest using something like time.windows.com

 

[yorkie]

That's not a valid NTP server.
Presumably you mean 1.uk.pool.ntp.org

Must've been an outdated page I saw then when... as a google searchg at the time showed 'server1' or 'server2' as the addresses.... although worth noting that for the Sricam camera I have used time.windows.com and and just pool.ntp.org and still get the same issue

 

[alastairstevenson]

Presumably the NVR and encoder time values are now correct.

Must've been an outdated page I saw then when... as a google searchg at the time showed 'server1' or 'server2' as the addresses.

Maybe what you saw showed the parameter line format for specifying NTP servers in Linux, such as :
To use this specific pool zone, add the following to your ntp.conf file:
server 0.uk.pool.ntp.org
server 1.uk.pool.ntp.org
server 2.uk.pool.ntp.org
server 3.uk.pool.ntp.org

although worth noting that for the Sricam camera I have used time.windows.com and and just pool.ntp.org and still get the same issue

The camera still needs to be able to resolve the NTP server name, and connect to the target site.
So DNS, gateway, routing all has to work correctly.
Suggestion :
I've seen some Chinese cameras not work well using the LAN gateway for DNS, maybe try Google's 8.8.8.8 and see if that changes anything.
Does the Sricam have a test button for the DNS setting?

 

[Teken]

Just some consideration and best practices as it relates to time keeping in no specific order of relevance or importance:

Local NTP: In the ideal world you would have and use a local NTP GPS PPS source. Doing so removes the need or reliance on any outside source or internet connection.

If deploying a local NTP server isn’t possible the next best thing is to implement a cheap and free NTP server on a computer that runs 24.7.365

There are dozens of free NTP applications available to use that cover Windows, Linux, Mac.

One Source: At a high level only one NTP system should provide time keeping. I would never recommend you point your cameras to the NVR / DVR vs to a dedicated NTP Server even if it’s just a PC.

Polling: If you use any public NTP System be aware polling too frequently will cause your public IP to be black listed. Thus you will never receive an NTP update as you expect.

As such using at least a minimum of four completely different public NTP servers that span government, military, schools, organizations is important.

If you rely on NTP Pools only you’re setting yourself to failure over the long run.

Firewall: Ensure port 123 is not blocked anywhere on the network.

DNS / IP: Generally speaking the whole idea and concept of DNS is that a person doesn’t need to remember a number.

So can use a friendly (human readable) name to use. Which also has the benefit that (IF) the IP Address should change it doesn’t matter because you’re using the friendly name.

Regardless, it’s very rare to see the NTP IP Address change! So best practice is to use both friendly name & IP address for a measure of fail over and redundancy.

Power / First Poll: You will find many devices do not reach out to a NTP Server during first start / power up. Whereas others once the POST has completed the very next thing it does is try to reach a NTP server to update the system time.

You’ll need to test and validate how your system behaves and operates. Many systems try only once at first boot than wait until the user defined value such as every X minute / hours.

While others try multiple times in a short period than wait until the user defined value. Very poorly designed hardware will revert back to some insane date / time until it can be updated by the NTP Server.

This specific problem is still present but not as common as years past.

Hence the need for a UPS to provide enough power / time during a grid down event to recover.

Time Zone / DST: As stated up above only a single NTP source should provide time keeping. But the time zone, offset, DST, must be defined and validated to hold and remain.

There are countless stories where a NVR override these user defined values on the camera. As such never point the camera to the NVR for time keeping.

 

[yorkie]

Maybe what you saw showed the parameter line format for specifying NTP servers in Linux, such as :
To use this specific pool zone, add the following to your ntp.conf file:
server 0.uk.pool.ntp.org
server 1.uk.pool.ntp.org
server 2.uk.pool.ntp.org
server 3.uk.pool.ntp.org

That is a strong possibility, lol.
The time does now seem to be showing right now after any reboot or power down event. Interestingly putting in 1.uk.pool.ntp.org or any of those others listed in the NTP setting for my samsung/wisenet cameras brings up an 'incorrect server' message - quite funny really seeing as they were fine with using server1.uk.pool(etc) even though that wasn't correct as i turns out.... so all I've done is just go with "uk.pool.ntp.org" and that seems to be working fine.

The camera still needs to be able to resolve the NTP server name, and connect to the target site.
So DNS, gateway, routing all has to work correctly.
Suggestion :
I've seen some Chinese cameras not work well using the LAN gateway for DNS, maybe try Google's 8.8.8.8 and see if that changes anything.
Does the Sricam have a test button for the DNS setting?

I had been using 168.126.63.1(/2) for DNS as this has worked well on everything else. There's no specific test button on the IP/DNS setting page... on the time setting page there is a button to sync with NTP but that's about as close as we get - which of course in the past it will sync correctly and then a few minutes later has gone back to +1 hour. I've just tried using 8.8.8.8 as the primary DNS server whilst I've been typing this, and in the time it's taken me to write out this post the time has jumped back +1 hour again.

One other little strange thing I noticed for another camera.... at the moment I'm trying to set up the Localhost function on the NVR so I don't have to run my 8m long patch cable from the ethernet switch upto the NVR, at the moment I've got it working with all the attached Hikvision devices, yet for any cameras using ONVIF such as the Samsung and Wisenet fisheyes there's no such luck - for the Samsung camera I set it up using an IP address as set reletive to the NVR's internal network card address but the localhost link for the web configuration page wouldn't work, so in the NVR camera configuration page I set it to use Samsung protocol instead of ONVIF and immediately the time displayed on the camera jumped by +1 hour; put the protocol back to ONVIF and the time went back to the correct value. tbh I might start a different thread regarding Localhost and ONVIF cameras as I get a feeling that might be yet another time sinkhole just as it has been trying to figure out this time jumping issue with the Sricam (overall spent about 5 or 6 hours on it collectively, and getting nowhere slowly)

 

[alastairstevenson]

so all I've done is just go with "uk.pool.ntp.org" and that seems to be working fine.

The time does now seem to be showing right now after any reboot or power down event.

That's good. One problem solved.

I've just tried using 8.8.8.8 as the primary DNS server whilst I've been typing this, and in the time it's taken me to write out this post the time has jumped back +1 hour again.

That's likely a Timezone or DST problem as opposed to an NTP problem.
I've seen this way back when a camera handles its own time sync but is also being managed by an NVR, which periodically updates the camera time using it's own values.
I don't recall what the fix was though. I may have disabled DST in the camera.
Presumably the NVR time and time configuration is looking normal and correct?