Warped Clock - Constant Problem

[specialk23]

Greetings all. Since building my Tivo I have had a warped clock problem. This is easily fixed by the steps in FAQ http://minnie.tuhs.org/twiki/bin/view/FAQ/MyTivoSaysIHaveNoGuideData

However, the same problem occurs about 4 weeks later. Does anyone know how I can permanently fix the problem. Would really appreciate some pointers

Cheers and thanks in advance

[thomson]

Does anyone know how I can permanently fix the problem.

You could schedule the "fix" every few days via cron. The following crontab entry will perform the actions every morning at 6am:

00 06 * * * (touch /var/timestamp; /hack/bin/force_index.tcl) &

[specialk23]

via cron.

thanks for that
Not exactly sure what you mean but will do some more reading and try to sort it. Thanks for answering my query

[dyrplq]

CRON is an automated process that runs command line commands at specified times. To access it;

Telnet into your TiVo
cd /hack/etc/

cp crontab crontab.bak (make a backup of your original file.. just in case ;) )

joe crontab
This will open your crontab file in the joe editor.

Make sure you leave a blank line at the end of the file otherwise it won't work
once you save it.

Make your changes, then Ctrl-H and Ctrl-S to save.

I don't think you need to reboot your tivo after updating your crontab file, but do it just in case.

Hope this is some help.

[petestrash]

running the touch command every couple of days will mask the warped clock issue, but does not fix the underlying problem.

Your TiVo is not contacting the timeserver correctly, it's internal clock will drift over time.

Depending on when you imaged your tivo, you may have used an image which contained a faulty ntpdate file. when did you image your TiVo.

The correct file is located here ntpdate (http://minnie.tuhs.org/twiki/pub/Uploads/WebHome/ntpdate).

One way to install is is by typing the following into a telnet session


cd /bin
rw
mv ntpdate ntpdate.old
wget http://131.244.9.101/twiki/pub/Uploads/WebHome/ntpdate
ro

To test whether your ntpdate file is working (either before or after upgrading it) just type the following into a telnet session.


/bin/ntpdate -b 192.43.244.18 129.6.15.29 132.163.4.103


if it works you should get a response showing your current time like.



gmtime gives 106/3/26 22:26:23 [3]
sending to clock 06/04/26 22:26:23 [3]


Peter.

[specialk23]

[QUOTE=petestrash]Depending on when you imaged your tivo, you may have used an image which contained a faulty ntpdate file. when did you image your TiVo.

Peter

Thanks fo that. I kind of figured there was something wrong with the image I used. Was planning to re-imagr but will try this first and report back. Thanks for your help

[specialk23]

dyrplq

Thanks for clarifying Cron. As you can tell I'm not that technical

Regds

specialk

[specialk23]

[QUOTE=specialk23][QUOTE=petestrash]Depending on when you imaged your tivo, you may have used an image which contained a faulty ntpdate file. when did you image your TiVo.

In November when I first installed Tivo

[petestrash]

I'm pretty sure it was already fixed by then, I think the bad file was in early 2005 images.

Let's have a look whats happening.

Force a daily call and then look in your otclient.log

scroll down and look for references to ntpdate. You should see a line like


Apr 27 17:00:37 (none) comm[117]: Setting clock. Command = "/bin/ntpdate -b 192.43.244.18 129.6.15.29 132.163.4.103"

If it's working the next couple of lines should look like


Apr 27 17:00:37 (none) comm[117]: About to execute: /bin/ntpdate -b 192.43.244.18 129.6.15.29 132.163.4.103 2>&1
Apr 27 17:00:43 (none) comm[117]: Command succeeded


Peter

[dyrplq]

What does it mean if you get "permission denied" when trying to manually run the "/bin/ntpupdate...." command?

Cheers, Phil

[thomson]

What does it mean if you get "permission denied" when trying to manually run the "/bin/ntpdate...." command?

The most common reason is that the command does not have "eXecute permission". You can check this by "ls -l /bin/ntpdate" where you will find that the first column (which shows the permissions) will look something like "-rw-rw-r--". The easiest way to fix this is to do a "chmod 755 /bin/ntpdate", after which the permissions should look like "-rwxr-xr-x".

[dyrplq]

Great. That was it. Now what does it mean when I get no response at all from running the ntpdate command?

[thomson]

Great. That was it. Now what does it mean when I get no response at all from running the ntpdate command?

I would have expected a usage message... something similar to:

usage: /bin/ntpdate [-bBdqsv] [-a key#] [-e delay] [-k file] [-p samples] [-o version#] [-r rate] [-t timeo] server ...

Are you able to provide the output of "ls -l /bin/ntpdate"? I am guessing it is a link to a differnet file (most likely a script). I unfortunately do not know very much about the OzTivo system installations, but I would have expected some sort of output to be produced.

[petestrash]

Thomson is right entering /bin/ntpdate should produce:

ntpdate [-B] [-b] [d] [-q] [-v] server [server ...]

Using the correct syntax /bin/ntpdate -b 192.43.244.18 129.6.15.29 132.163.4.103 should produce:

gmtime gives 106/3/29 10:14:27 [6]
sending to clock 06/04/29 10:14:27 [6]

Peter.

[Muzza]

I seem to be having this fault also (constantly getting the warped clock issue). I have followed through these posts and have got to this final message which states I should see a result but unfortunately I don't (although there is no error either like earlier when I had the "permission" error). What next?

Thanks in advance.
Muzza.

[dyrplq]

Likewise Muzza, I also dont get a response from this command, so I run the touch timestamp command via Cron each night. I know that this is a 'workaround' and that I shouldn't have to do this at all, but it works for me.

Cheers, Phil.

[petestrash]

When you say running the command does not produce any result, how long did you wait?

depending on your TiVo's load it could take around a minute or so to produce a report.

So when you say it does not produce the result, does it come straight back with a prompt or only a cursor square? If cursor square, this is correct and when the fetch is completed the results should show.

Can you both please try the following and post the results.


[TiVo [p0] ~]#
[TiVo [p0] ~]# cd /bin
[TiVo [p0] /bin]#
[TiVo [p0] /bin]# ls -l ntpdate
-rwxr-xr-x 1 0 0 59473 Apr 23 2005 ntpdate
[TiVo [p0] /bin]#
[TiVo [p0] /bin]# /bin/ntpdate -b 192.43.244.18 129.6.15.29 132.163.4.103
gmtime gives 106/4/15 09:37:09 [1]
sending to clock 06/05/15 09:37:09 [1]
[TiVo [p0] /bin]#


Peter.

[Muzza]

This is the result I get......

[TiVo [p0] ~]# cd /bin
[TiVo [p0] /bin]#
[TiVo [p0] /bin]# ls -l ntpdate
-rwxr-xr-x 1 0 0 59473 May 15 08:51 ntpdate
[TiVo [p0] /bin]#
[TiVo [p0] /bin]# /bin/ntpdate -b 192.43.244.18 129.6.15.29 132.163.4.103
[TiVo [p0] /bin]#
[TiVo [p0] /bin]#

I noticed that it was actually 8:09am May 16 when I did this but if you see above it says a different time and date (maybe that is normal though??).

I have been carrying out a: "touch /var/timestamp" & "/hack/bin/force_index.tcl" continusously over the last few days but my TiVo just won't sort itself out now. This always used to fix the fault for several weeks but now I have been unable to get a successful guide data update for about a week (and of course season passes etc don't work). Last night (after a TiVo restart), I managed to get some data back but it again failed at about 10% or so. Ususally over the last week, I get "failed while preparing data" at about 1%. I have still got no data on several channels.

Getting frustrated now......any ideas??? :(

[petestrash]

Ok, it sounds like your tivo is having issues calling out to the internet. This is probably why you also don't get a result from the ntpdate command.

try following the steps @ Configuration_and_Diagnostics (http://minnie.tuhs.org/twiki/bin/view/Network/NetworkingHowto#Configuration_and_Diagnostics) to see why your TiVo is not responding.

Peter.

[Muzza]

As far as connectivity goes - a test call always works ok and it says it connects ok and has finished downloading ok when you do a normal daily call from TiVo-Web but it just fails when it prepares the data. This always used to come right once a index fix had been run but doesn't seem to be this time round.

I will however look through the link you supplied when I get home just in case.

Cheers.

[petestrash]

a 'Test' call will often work even if you have Proxy issues with your ISP.

Peter.

[Muzza]

It all looks ok to me (networking wise) and it seems odd that it would suddenly change as far as ISP or network config goes.

It definately starts to prepare/transfer guide data which would imply that it already has finished with the internet side of things I would have thought. It seems to be failing at the TiVo OS to me. The question is ....why??

[NZMarke]

I'm getting exactly the same problems/symptoms as Muzza.

Last time I had the same problem I stuffed around setting the date and time manually, then doing a touch /var/timestamp and forced a reindex as well.

PetesTrash : quick question. The ntpdate call that you suggest putting into the crontab. What are those server ip addresses that it's calling ... standard ntp servers? In which case should we (Muzza and I are both in NZ) be using NZ-based ntp server addresses instead of the ones you listed in your example?

And where can we see what the timezone settings are on the tivo .. to check that it is set correctly? I'm assuming that the ntpdate call gets the GMT time from the NTP server then calculates the correct time from GMT +- timezone offset?

Like Muzza, what I'm seeing is that the call completes, the download is successful, but then the indexing process fails during the "preparing guide data" stage. So I don't think there's a network problem ...

Cheers

Mark

[NZMarke]

Hi all,

Not sure if this is relevant to the problem, but I've got a message in tverr.log:

May 16 22:39:06 (none) TmkTransform::Trace[161]: Have a buffer (0) with zero segmentsDid someone zero memory?
May 16 22:39:06 (none) TmkTransform::Trace[161]: leaking buffers = pt->theBuf = 0x30301000. Trying to recover.
May 16 22:39:39 (none) last message repeated 27 times
May 16 22:39:39 (none) last message repeated 27 times

Anyone know what this means?

Cheers

Mark

[petestrash]

It definately starts to prepare/transfer guide data which would imply that it already has finished with the internet side of things I would have thought.

If the file was corrupted or truncated, the download would still appear to be ok and only fork during loading.

Peter

[petestrash]

PetesTrash : quick question. The ntpdate call that you suggest putting into the crontab. What are those server ip addresses that it's calling ... standard ntp servers? In which case should we (Muzza and I are both in NZ) be using NZ-based ntp server addresses instead of the ones you listed in your example?

I haven't suggested putting the ntpdate command into crontab. It should be automatically run during the daily call each day. I haven't bothered checking where these servers are located, but they are standard NTPservers. The same ones that are built into the image, so if it doesn't work manually it's not going to work during a daily call. It only needs one of the address to work successfully.


And where can we see what the timezone settings are on the tivo .. to check that it is set correctly? I'm assuming that the ntpdate call gets the GMT time from the NTP server then calculates the correct time from GMT +- timezone offset?

The TiVo thinks it's in GMT, but the oztivo image works out the correct timezone based on your postcode.


Not sure if this is relevant to the problem, but I've got a message in tverr.log:
...snip...
Anyone know what this means?


This is usually the first signs of the event bug and the TiVo will soon freeze and reboot, it should be un-related to the other problems. If it hasn't already rebooted, it's probably an idea to do it now manually.

Peter.

[Muzza]

After a suggestion from NZMarke on the NZ forums I ended up doing a "Clear program data & ToDo list" last night and getting the whole program guide from fresh. Which seems to have worked fine. It took about an hour to do the clearing of the data, then a while to reload (I forced a call from TiVo Web) and reindexed again, restored my backed up season passes etc and so far so good.

I suspect this will only be for a few weeks though and then I'll get my "warped clock" issue again so we still need to work out why it happens.

[petestrash]

It does seem a little strange the only people currently with warped clock issues and data failing to load are both from NZ.

Maybe there is an issue with one of the NZ emulators or a bad slice.

Peter.