08-18-2011 06:39 AM
As said above it is always near the top of the threads:
Logitech Support Specialist
If a reply adequately addresses your technical issue, please click on the "Accept as Solution" and "Give Kudos" button so this information can benefit other users via search.
08-19-2011 01:47 PM
Just wanted to add an observation here...
I was having the same problem where the Alert Time Stamps were incorrect.
I followed "some" of the steps outlined earlier, but I did NOT reset the camera:
1) Exited Commander
2) Deleted the xml file
3) In Windows Vista, right-clicked on system clock, chose Adjust Date/Time
4) Clicked the Internet Time tab
NOTED here that it was using "time.windows.com" and it had NOT successfully synchronized
5) Clicked Change Settings, Clicked Update Now several times... again... it did NOT sync with time.windows.com
6) Changed the Time Server to "time.nist.gov", Clicked Update Now, it DID sync.
7) Restarted Commander
8) The time stamps are now correct on the camera alerts.
This makes me wonder if the cameras are using the same Time Server as the computer that is hosting Commander.
If someone has this problem again, it might be interesting to see if "just" changing to a different (working) Time Server corrects the problem. Just do the following:
A) Exit Commander
B) Switch the Timer Server on the host computer; Assure that it is working
C) Restart Commander
08-19-2011 03:17 PM - edited 08-19-2011 04:00 PM
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/NTPPoolSer
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
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.
08-19-2011 07:16 PM
You have saved me alot of grief, I followed your methods.
After a 15 minute power outage (first one since I got the cameras 3 months ago), one of the cameras reset to 2010. I originally thought the camera was NOT dowloading the recording. Of course it was, just that it was indexing them to January 2010.
Here's what I did.
1) Closed commander
2) Deleted the index .xml file
3) Checked my internet time server, when I hit "update" it continuously failed.
4) Switched my time server to time-a.nist.gov (any responding server would work i guess)
5) Restarted commander and left everything alone for 2 hrs, when I returned all my recordings were being saved on current date and time and everything was back to normal.
6) Didn't have to reset or unplug at all. I do not like resetting.... Reset my first indoor camera a few times because of connectivity problems and it stopped booting up..... good thing it was only 4 days old so I returned to Bestbuy for a more hardy outdoor camera.... So again, I don't reset.
08-20-2011 12:29 PM
Thank you for the great explanation and fix Daniel. It was perfect timing!
This happend to me today. It looked like the video clips were not being downloaded to my computer. Taking the card out showed it was downloading them, but to January 1, 2010.
A quick search of the forum and I found your post. I'm glad I did! Resetting the time server was certainly an easy and quick fix.
08-23-2011 08:46 AM
Daniel & John Thanks for the info. I have been having the same issue and your suggestions worked perfectly. I do have a question though. will it be possible that on your next realease you have an easier way of fixing this. perhaps a button to click where it will actually to this steps. Also when this whole time stamp issue was happening for me I noticed there were some LMN files located under the the Logitech Alert Recording folder same folder where I have te MediaRecordingIndex.xml file. What is the difference between the LMN and LMR files. I've seen the LMR files corresponding to the recording date of the file but I don't know what the LMN file is.