Daylight Savings. How did everyone's cameras do?

[prsmith777]

I had one camera misconfigured and didn't do the shift. All the others made the change fine.

My big PTZ SD8C845FG-HNF did the change fine, but has locked up and won't accept PTZ commands through the web interface. This happened the last DST also, so I am guessing it is a bug. I had to default the camera to get it working again last time. Sigh

 

[Parley]

I manually synched mine. I only had to do one camera on each NVR. No problems.

 

[Mike A.]

Some ONVIF errors related to the time change that also affected PTZ control:

PTZ controls suddenly stopped working

Camera is a Dahua SD4A425DB-HNY. PTX controls were working fine yesterday. Today I get no response. I changed nothing but went thru all the settings anyway and found nothing amiss. I've rebooted the camera and server and nothing changed. PTZ still not working. PTZ in the camera itself works...

ipcamtalk.com

 

[bp2008]

All mine did fine. I'm pretty diligent about setting up DST correctly on every camera I set up, and none have exhibited any bugs in that department.

 

[Rob2020]

All my Andy Dahua synced up with no issues.

 

[wittaj]

Not related to Daylight Savings, but I was pulling up my cameras to confirm they all went to the proper time and noticed even though I have an NTP setup (The NetTime tool most use here), they are all off from each other anywhere from 1 second to 2 minutes.

I am using the dual NIC and have all of the cameras on the 10.1.1.x subnet with the BI computer at 10.1.1.50 and have pointed the cameras to 10.1.1.50.

The other NIC is the internet at 192.168.2.x subnet.

Something that might be related is that I noticed the logfile for NTP doesn't show any updates after 1/15/21 - so maybe something is wrong with it? Of course that far back I have no idea what changes may have happened and I guess I am lucky my cameras are not further off on time.

I have confirmed the firewall allows port 123.

Many of my camera logs show it going out at the specified time interval to grab from the NTP, but it doesn't appear to change it.

Here is an example from the new GUI - you can manually update it to the NTP and you can see it says "operation successful", but you can see that the NTP says 11:38.31 and the camera says 11:39.12. The only way I can get the camera to match the NTP is if I turn off NTP and hit the "Sync PC" option.





What is painfully obvious that I am missing LOL

 

[prsmith777]

Some ONVIF errors related to the time change that also affected PTZ control:

PTZ controls suddenly stopped working

Camera is a Dahua SD4A425DB-HNY. PTX controls were working fine yesterday. Today I get no response. I changed nothing but went thru all the settings anyway and found nothing amiss. I've rebooted the camera and server and nothing changed. PTZ still not working. PTZ in the camera itself works...

ipcamtalk.com

Thanks that was real helpful and I was unaware of these issues (have been pretty absent here lately)

I managed to get the PTZ working by switch from ONVIF XML to Dahua New V4

 

[bp2008]

@wittaj
Make sure the firewall rule for port 123 specifies the UDP protocol. Also make sure there are no other firewall rules that conflict and block this traffic.



In NetTime settings, confirm the state of the checkbox "Allow other computers to sync to this computer".



Further, there's a simple Windows program you can use to test an NTP server: Galleon Systems - NTP Check You could run that on another PC to verify the NTP server is reachable from other LAN devices.

 

[bigredfish]

I manually synched mine. I only had to do one camera on each NVR. No problems.

Ditto. The 4 NVRs I manage took me about 10 minutes. Time pushed to all cameras fine.
I did have 2 LPR cameras I run Schedule profile on and 2 that I use split SmartPlans on that I had to go in manually and re adjust

 

[wittaj]

@wittaj
Make sure the firewall rule for port 123 specifies the UDP protocol. Also make sure there are no other firewall rules that conflict and block this traffic.

View attachment 177095

In NetTime settings, confirm the state of the checkbox "Allow other computers to sync to this computer".

View attachment 177094

Further, there's a simple Windows program you can use to test an NTP server: Galleon Systems - NTP Check You could run that on another PC to verify the NTP server is reachable from other LAN devices.

Yes, port 123 is UDP.

The "allow other computers to sync to this computer" is checked.

I just tried that NTP check from another computer on the 10.1.1.x subnet and it all came back as ? so I am assuming that means it wasn't reachable?

 

[bp2008]

Correct. If it was reachable then a lot of info would be shown.

My guess is that Windows Time service is listening on UDP port 123 already, and not actually providing the time sync service. This is common on Windows machines. You can see that if you launch "Resource Monitor" on the machine running NetTime, you can go to the network tab and look in Listening Ports to see what is listening on UDP port 123. If Windows Time service is responsible, it will be svchost.exe (LocalService) listening on this port. Try disabling "Windows Time" service in Window's service control panel services.msc and then restart the NetTime service and see if it manages to work.

It shouldn't matter if Windows Time is disabled, because NetTime will be doing your time sync duties better than Windows TIme ever did anyway.

 

[Mike A.]

Also check in Windows services for W32time running. If so, disable it. It can grab port 123 before NetTime.

Oops... cross-posted with bp re same thing.

 

[tigerwillow1]

The cameras did fine switching from DST, but that extra hour seems to have vaporized on the NVR. Does BI do something to handle the extra hour?

 

[wittaj]

Correct. If it was reachable then a lot of info would be shown.

My guess is that Windows Time service is listening on UDP port 123 already, and not actually providing the time sync service. This is common on Windows machines. You can see that if you launch "Resource Monitor" on the machine running NetTime, you can go to the network tab and look in Listening Ports to see what is listening on UDP port 123. If Windows Time service is responsible, it will be svchost.exe (LocalService) listening on this port. Try disabling "Windows Time" service in Window's service control panel services.msc and then restart the NetTime service and see if it manages to work.

It shouldn't matter if Windows Time is disabled, because NetTime will be doing your time sync duties better than Windows TIme ever did anyway.

Also check in Windows services for W32time running. If so, disable it. It can grab port 123 before NetTime.

Oops... cross-posted with bp re same thing.

OK those were running so I disabled them and restarted the computer.

Still no joy.

NetTime only thing on 123. Now I am stumped.

 

[looney2ns]

All cams here changed over on their own fine.
Even a new one that I have up testing for review.

 

[Mike A.]

@wittaj Try running that test program on the same machine as NetTime. See if any response then.

Looking at mine, NetTimeService on UDP port 37 is different. Shows "Allowed, not restricted." Not sure why port 37 would matter or why it would be listening on it but maybe try opening that too.

ETA: Looking more, UDP port 37 appears to be associated with TIME protocol services but should be deprecated to NTP. Maybe NetTime listens to pick up old requests for that as well. I wouldn't think that it would matter for your issue but

 

[wittaj]

@wittaj Try running that test program on the same machine as NetTime. See if any response then.

Looking at mine, NetTimeService on UDP port 37 is different. Shows "Allowed, not restricted." Not sure why port 37 would matter or why it would be listening on it but maybe try opening that too.

ETA: Looking more, UDP port 37 appears to be associated with TIME protocol services but should be deprecated to NTP. Maybe NetTime listens to pick up old requests for that as well. I wouldn't think that it would matter for your issue but

OK the NTP check tool is now showing it can connect to the NTP from other devices on that LAN.

In resource monitor I can see camera IP addresses hitting the NTP, but it isn't being logged in the NTP log file?

 

[Mike A.]

I hadn't looked before since mine are working fine but I just checked the NetTime log for mine and I see the same. I have nothing since 5/52023. So doesn't seem to be unique to you. I tried stopping and restarting the service and made multiple attempts from several different devices but still none show in the NetTime log.

Is NTP working now?

ETA: Seems to be a display issue with NetTime. If I go to C:\Program Files (x86)\NetTime and pull up the log file, then it does show the most recent attempts. The program just isn't displaying them for whatever reason. I deleted the log file and new attempts do show now. Maybe hitting a limit for number of entries or file size.

 

[wittaj]

OK - thanks to you and others helping me troubleshoot!

I guess I will do some more testing and confirm it is working by manually making some cams the wrong time and then running NTP.

Somewhat related question. I found the actual log.txt file for NTP and it shows it worked up until about a month ago, not 2021 like the log showed from the NTP screen (I guess that screen only pulls so many lines).

So what I think happened is that when I setup NTP I must have disabled the windows time at that point.

About a month ago my LPR utility was throwing errors related to the computer time.

When I was investigating that issue I had found that the computer time hadn't synced in years and must have finally got to the point that it was far enough off to throw errors with LPR.

In looking at it I can't seem to get Windows to point to my NTP to pull time, so I guess with "windows time" being disabled I may get the LPR error in a few years.

So the question is how to I get the BI computer to pull time from the NTP while still leaving "Windows Time" disabled?

 

[Mike A.]

I edited the post above if you didn't see while posting. Delete the log file and you should see new attempts.