Time Drift On A Recorder Without Internet Access

If the time drifts on a DVR, could there be the possibility that the footage could be thrown out of court in the event of a robbery

Anything is *possible*, though the probability of that is pretty low unless the time is off by a massive amount (days).

There seems to be a lot of FUD about video being thrown out if anything about it isn't perfect. Think about all the other kinds of evidence admitted, rarely is any one piece of evidence completely 100% irrefutable. That's why a defense or prosecution attorney will generally have multiple pieces of evidence to present.

If anything is over-the-top pointless it's likely to be thrown out, but time skew on video (or 5fps, or h.264) is not something that commonly gets video thrown out.

Video that is blurry, shows no distinguishing value or has other flaws that inhibit the visual value are more likely to cause it to be inadmissable.

For your specific case, there are GPS network clocks that can act as an NTP server.

Background reference: NTP / Network Time Guide For Video Surveillance

If you are concerned about this, the best solution is the following:

Dedicated GPS Servers

In systems where accurate time is required but the surveillance system is not connected to the internet, dedicated GPS based time servers are used. These devices retrieve time from GPS satellites via antenna, either mounted to a window or external, and act as NTP/SNTP servers for the rest of the network.

Dedicated GPS time servers sell for about $800 USD online (Veracity Timenet) and up. Advanced servers (such as Spectracom and Meinberg) with extremely precise nanosecond accuracy, redundant external antennas, and other advanced features sell for easily 2-3 times this price, or more.

In our experence this is more of an issue when you have multiple NVRs or DVRS. When you only have one recording device the time may be off but the camera are normally still sync'd.

We have a customer which they had a case thrown out with there previous system which they had 16 DVRs and the time was not sync'd between them. They had a break-in and the video (camera on DVR A) showed the suspect stealing and at the same time (Camera on DVR D) he was sitting at the bar.

The system has since been replaced with NVRs which are time sync'd so they no longer have this issue.

I am not sure why this issue arises. Outgoing initiated internet traffic that is periodic in nature & does not hold a continuous session, posses virtually no risk as it will use a dynamic port on the firewall which will automatically close when the time check completes. This type of traffic is much different to traffic initiated from the outside which will require a port forward or VPN or the like to be able to reach the intended destination on the network.

Port forwards leave a permanent hole in the firewall that can be exploited by a hacker. But a port forward is not required for a DVR to access an external time server.

If they still insist on not allowing outgoing internet traffic, then an option is to set up a time server on a workstation or NAS that is allowed internet access & then refer the DVR to the workstation for time sync.

Ah yes, unconnected systems and time sync... these were the bane of my existence for several years with one client in particular. Nobody ever cares enough about time sync until something happens and then they can't find the video they want because the clock never matches their paypoint systems (which DO have access to a time server). And a big fuss is made about it at the time, the problem is explained AGAIN, solutions are offered AGAIN, and by the time someone decides it's not worth the trouble or expense, nobody cares about it any more anyway. At least not until the next time. Same goes for cameras being down or a system beeping incessantly for weeks because a drive has failed - everyone just ignores it until they need some video, then OF COURSE the video they need is on the dead drive, or should have been captured by the dead camera.

There was one instance with a lottery fraud investigation, where the lottery people were concerned enough about accurate time sync (matching the video time to the time on the lottery terminal, so they could ID the person buying tickets with a stolen credit card) that they brought me in to spend time with their investigator - he'd print a ticket, bring it back to me, and we'd compare the timestamp on the ticket to the time on the DVR. Did this several times, in fact... then he had me write a two-page statement on why the time was wrong and how we determined the proper offset. If you can use a method like this to prove time offset, there should be no problem in court.

Of course, none of this is new to DVRs - part of our annual preventative maintenance on the ol' MUX-and-VCR systems was correcting the time on the MUX, which was always off by at least a couple hours from the previous year... and those didn't even have network time sync as an option. Most didn't know how to handle DST either.

As far as camera vs. DVR timestamp, we've always used the DVR-based one - if the camera has onscreen time display, I'll generally turn that off entirely. In the lottery example above, they originally called me in because the cameras were showing a timestamp in 1970 - they were IQs and the installer hadn't set the time or disabled the onscreen display, and the investigator kept fixating on that instead of the DVR's time display in the playback window.

Keep in mind that camera timestamps really only apply to IP cameras, so if you still have an analog or hybrid system, you still need the DVR's timestamp. As you move from analog to hybrid to all-IP, it just makes sense to keep that time source consistent, especially if you're still using the same VMS.

Time synch can be a big deal on any video system due to the distributed nature of many of the components. We tend to need to synchronize timestamps down to the second or subsecond for best performance. And in some extreme cases (as cited above) even to work with video.

Some shops take a pretty heavy handed attitude towards network security, that being there shouldn't be one (a network that is) but rather an isolated enclave of systems with no functionality outside of themselves. I believe they will hang on for many years just as analog has, and may in fact take some permanent form, but will become increasingly rare.

In the mean time, the local NTP server is the most straight forward and direct solution. Go ahead and propose they get one or live with the consequences.

Matt, I have had to go to court with the video on a few occasions. Typically if you can explain it to the Judge's satisfaction (laymen's terms) he will allow it. It all depends on the judge really and most have common sense. Long story short, the Coroner established a time of death as 6pm. An hour later the suspect is at the ATM with the victim's ATM card, but the time still says 6pm. The teller had not changed the time to allow for Daylight Savings Time. Yeah, you have to throw the teller under the bus, but the suspect needs to be in jail. There was other evidence that helped establish his guilt, but his face in the video, with her card, she's dead.

OK, that brings about a question on a particular brand. Axis cameras on an Exacq system send a timestamp with the video. For instance, an installer didn't do his do-dilligence and forgot to set the time in a camera. The TZ was still set for GMT. The NVR was set to CST-6. The footage they were looking for was recorded at noon but showed up at 6:00 pm when they searched for it. It had the 12:00 timestamp but didn't show up until 6:00pm. Weird part was, we found it by searching that day at 3:00.......It appeared that the footage was recorded in the future.

Has anyone else experienced this with Axis cameras on Exacq?