Good timing John, and great observation - you beat me to the punch. I've been working on getting a reply on the time issue, and your suggestion of changing time servers was one of the main new suggestions.
So, every time Commander connects to a camera, it sends down the PC's:
- current time
- current time zone
- current time server
When Commander sends the time info to the camera, the camera saves the time server and time zone, and sets the camera time to the time sent by Commander. The camera will then "poll" the time server every 9-15 hours (as it is right now). If Commander is connected to the camera, Commander should also re-send this info down to the camera every 11 hours (as it is right now). It uses the same time server as the PC to in theory keep them both synced to the same time server.
When a camera boots up, as part of the initialization, it tries to get a good time from the time server as well, so you don't have to have Commander running.
On Windows, the default time server is time.windows.com. The camera defaults to using the time server time.nist.gov right now (when new or reset), until Commander sends down a different time server (usually time.windows.com). One of the problems we've recently tracked down is that time.windows.com can be very unresponsive at times. Unresponsive enough that every retry times out. It seems to have gotten worse too recently. There are also times that setting the time from Commander isn't working as well as it should.
So, a good work around right now is to do exactly like you listed above, probably using the simpler list:
1. Exit Commander.
2. Change the time server on the PC running Commander. Use "Update Now" a few times to check it. Picking a good time server might be the tougher part. It's better to use a time server geographically near you, and a less busy time server if possible. You can use pool.ntp.org, or one of the more specific country ones like us.pool.ntp.org - those will cycle through different time servers on each request. See http://support.ntp.org/bin/view/Servers/NTPPoolServers about pool.ntp.org, or for some other lists of time servers, see http://tf.nist.gov/tf-cgi/servers.cgi , http://support.ntp.org/bin/view/Servers/StratumOneTimeServers , or http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers (note the location).
3. Restart Commander.
Also, to try to fix up a time problem on a camera, you could try restarting Commander (maybe more than once).
If you have some recordings made when the camera had the wrong time, most of the time you shouldn't have to delete the recording index XML file. However, if the camera ever had the wrong time, and it was in the future, deleting the recording index XML while Commander is not running will help.
In the next version, we will have improvements around time stuff. For example, the next update will
- Work better with a "slow" time server
- Try again sooner if all the retries failed.
- Black list time.windows.com on the camera (if Commander sends that down, we'll use a better one)
- Use a better default time server than time.nist.gov
- etc.
When the camera boots up after having been off for more than a moment, it will lose its time, and the camera goes back to January 1, 2000 UTC (which is then offset by your timezone – so for California in the summer, it goes back to Dec. 31, 1999 5:00 pm). The timezone setting is preserved through reboots, so once its set, it stays set until the camera is reset. A camera will try to obtain a time from an internet time server very early on in the camera initialization. We hold off final camera initializations until we’ve given it something a few seconds to get a good time. If a good time could not be obtained in the first few seconds, it keeps the time it had, and proceeds with camera initialization (it will retry later). After the camera is initialized, and a recording is triggered, we do an extended check on the first recording to see if we have a “trusted time” yet or not (from either an internet time server, or a local client).
a. If we have a trusted time, we just use the camera’s date/time.
b. If the camera does not have a trusted time, the camera will find the end time of the last recording, and force the camera date/time to 1 minute after the end time of the last recording.
c. If there is no last recording on the SD card currently, the media recording management forces the date/time to Jan. 1, 2010.
d. If we make recordings without a trusted time, there is a flag set in the index to track the fact that the time is not trusted.
Also, beware that if you run a camera in "stand alone mode" (no path to the internet, no local client), the time of recordings during that time will be off. If you run a camera in stand alone mode on purpose, it's better to make at least one recording with an internet connection or Commander discovering the camera.
-Daniel
