Failed while preparing data.....AGAIN.

**DavidClarke** · 02-06-2006, 04:16 PM

Originally Posted by petestrash

My guess is that a lot of people have just added the touch command to a cron job as others have recommended in different threads, without fixing the actual cause of the clock warp or stopping the TiVo's time from drifting.

Bingo

Trying without the cron job for a while, but have had about 8 warp issues in as many months since I built my Tivo. Not sure if it now needed or not..

Suggestions welcome.

**petestrash** · 02-06-2006, 05:38 PM

Originally Posted by DavidClarke

Not sure if it now needed or not..

That depends on what is happening at your TiVo.

You need to have the modified postcodezones file.
you should be able to successfully run ntpdate -b 129.6.15.29
and finally after forcing a daily call check the otclient.log for a line like:

Code:

Jun 1 17:00:39 (none) comm[155]: Setting clock. Command = "/bin/ntpdate -b 192.43.244.18 129.6.15.29 132.163.4.103"
Jun 1 17:00:39 (none) comm[155]: About to execute: /bin/ntpdate -b 192.43.244.18 129.6.15.29 132.163.4.103 2>&1
Jun 1 17:00:52 (none) comm[155]: Command succeeded

If all these are correct you should no longer need the line in cron.

Peter.

**DavidClarke** · 03-06-2006, 03:31 PM

Originally Posted by petestrash

That depends on what is happening at your TiVo.

You need to have the modified postcodezones file.
you should be able to successfully run ntpdate -b 129.6.15.29
and finally after forcing a daily call check the otclient.log for a line like:

Code:

Jun 1 17:00:39 (none) comm[155]: Setting clock. Command = "/bin/ntpdate -b 192.43.244.18 129.6.15.29 132.163.4.103"
Jun 1 17:00:39 (none) comm[155]: About to execute: /bin/ntpdate -b 192.43.244.18 129.6.15.29 132.163.4.103 2>&1
Jun 1 17:00:52 (none) comm[155]: Command succeeded

If all these are correct you should no longer need the line in cron.

Peter.

All above checks out, so will leave the CRON job ## out. Much thanks

**Hoon** · 26-06-2006, 09:42 PM

OK I posted last month thinking my issue was fixed (before all this postcodes stuff) but its happened again this month. I see there's been a bit of activity in this thread during my absence which has been great.

So I have corrected my postcodezone file with the Auckland entries and now ntpdate is recognising my 02113 postcode which it wasn't before:

[TiVo [p0] ~]# /bin/ntpdate -v -v -v -s 210.48.107.133
/bin/ntpdate: invalid option -- s
Our postcode is 02113. Found matching timezone Pacific/Auckland
Offset 0 for timezone GMT, daylight saving is 0
Connecting to time server 210.48.107.133
Setting the local time to Mon Jun 26 11:14:33 2006
gmtime gives 106/5/26 11:14:33 [1]
sending to clock 06/06/26 11:14:33 [1]

fixtivotime is also successful with:

[TiVo [p0] ~]# fixtivotime
Our postcode is 02113. Found matching timezone Pacific/Auckland
Offset 0 for timezone GMT, daylight saving is 0
Connecting to time server 207.126.98.204
t was 3360309887 from server
t is now 1151321087
Time is 2006-06-26 11:24:47
Time set to: Mon Jun 26 11:24:47 2006
Have a nice day.
Time set to: Mon Jun 26 11:24:47 2006
Have a nice day.

However the correct time is 23:34, now my problem is my offset is 0 instead of GMT+1200. I have tried running timezoneadj30.tcl and setting this manually to +1200 but this makes no difference as my phone call still fails.

How does ntpdate identify the GMT offset and how do I modify this??

**petestrash** · 26-06-2006, 11:01 PM

Have you rebooted since updating the timezone file?

Peter.

**Hoon** · 27-06-2006, 07:01 AM

Yes I have rebooted several times.

I have just done a "Clear and delete programs and todo list" and now the phone call is successful however my time is still 12hrs out.

**Wibble** · 27-06-2006, 11:06 AM

Can you check that the timezone file is the right size: 870 bytes
ls -la /hack/zoneinfo/Pacific
-rw-r--r-- 1 0 0 870 Aug 21 2004 Auckland

If it was ftp'ed as ascii it will be the wrong size and corrupted.
(From bitter experience)

**Hoon** · 27-06-2006, 01:53 PM

No it looks fine.

-rw-r--r-- 1 0 0 870 Jun 26 10:09 Auckland

**petestrash** · 27-06-2006, 01:59 PM

Also check the space between 02113 and Pacific/Auckland is a tab and not just a space using the 'cat -et /etc/postcodezones' command.

Though it is strange that ntpdate is associating 02113 with Pacific/Auckland, but not setting the offset.

Also re-reading your post, you say that the phone call still fails. The offset being wrong won't cause this, just your guide times will be out.

Peter.

**Hoon** · 27-06-2006, 07:27 PM

Yep my postcodezones has tabs in it. My phone call is working now since doing a clear and delete, just my tivo time is out by 12:00. I can manually correct the time using settime but it just reverts back again when my next phone call is made.

Thanks for everyones help. If I can't fix this then I may have to reimage.