Failed while preparing data.....AGAIN.

Quote:

---

Originally Posted by DJC

Lets keep on it, can you do the same and post but use the -et flag on cat

cat -et /etc/postcodezones

---

[TiVo [p3] ~]# cat -et /etc/postcodezones
# A list of TiVo postcodes and the timezones that they represent$
# Two columns, separated by one tab only.$
#$
00800^IAustralia/Darwin$
02000^IAustralia/Sydney$
02600^IAustralia/Sydney$
03000^IAustralia/Melbourne$
04000^IAustralia/Brisbane$
05000^IAustralia/Adelaide$
06000^IAustralia/Perth$
07000^IAustralia/Hobart$
$
# New Zealand$
02112 Pacific/Auckland$
02113 Pacific/Auckland$
02114 Pacific/Auckland$
02115 Pacific/Auckland$
02116 Pacific/Auckland$
[TiVo [p3] ~]#


ARRRRGGGHHHH!!!!!! Memo to self to never cut and past into JOE...

Now:

[TiVo [p3] ~]# cat -et /etc/postcodezones
# A list of TiVo postcodes and the timezones that they represent$
# Two columns, separated by one tab only.$
#$
00800^IAustralia/Darwin$
02000^IAustralia/Sydney$
02600^IAustralia/Sydney$
03000^IAustralia/Melbourne$
04000^IAustralia/Brisbane$
05000^IAustralia/Adelaide$
06000^IAustralia/Perth$
07000^IAustralia/Hobart$
$
# New Zealand$
02112^IPacific/Auckland$
02113^IPacific/Auckland$
02114^IPacific/Auckland$
02115^IPacific/Auckland$
02116^IPacific/Auckland$
[TiVo [p3] ~]#

AND... WAIT FOR IT>>>...

[TiVo [p3] ~]#
[TiVo [p3] ~]# /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 43200 for timezone NZST, daylight saving is 0
Connecting to time server 210.48.107.133
Setting the local time to Wed May 31 20:32:35 2006
gmtime gives 106/4/31 20:32:35 [3]
sending to clock 06/05/31 20:32:35 [3]
[TiVo [p3] ~]#

Where do I send the beer???????? Mate!:) :) :)

I guess I just wait and see if the "warped clock" returns now over the next couple of days??

If not......thank you all so much for your help!!!!

Happiness is....a working TiVo!
:D :D :D

Welcome.

Should be right I think. I've never had a warped clock.

Cheers/DJC

Thanks guys, have #'d out the CRON file I wrote to :

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

Shouldn't be required and was at best a work around to bandaid the problem but sometimes messed up the TiVo suggestions for a day.

Appreciate the help, the 1.4 image I used was quite early and obviously has some issues...

Quote:

---

Originally Posted by DavidClarke

Appreciate the help, the 1.4 image I used was quite
early and obviously has some issues...

---

I don't think there was an image problem, ntpdate was the correct version.

It's been standard practise for NZ'ers to setup postcodezones on images prior to the release of the NZ specific images.

This is pointed out on the nztivo wiki, in the 'setting timesync up for New Zealand' section but, it is a bit (a lot) dated now.

AKL being missing from the tz file is certainly an issue.

I would like to know how have the affected units been running for months, without this coming up earlier.

Peter.

I got up this morning to find that TiVo had recorded one of my season passes and also 2 "TiVo Suggestions" during the night. It's been a long time since I've had that!!!

Hooray and thanks again for your help everyone!!!
:D :D :D

Hi all,

I've been lurking on this thread waiting to see if any solutions emerged. And they have. Like the others, my problem was with the postcodes file. But unlike them I had actually added the AKL postcodes in - 'cause the link in the instructions that links to the Auckland postcode file is actually broken .. so I manually added it using vi.

What I hadn't done though was realise that there was a tab (not a space) between the code and the location. I'd used a space ... and it doesn't like it. Re-edited the file to introduce a tab, and ntpdate now works happily as.

In reply to PetesTrash question "why have affected units been running without problems?" A couple of thoughts/points spring to mind :
1) I thought that mostly the people who had incorrect Postcode files WERE actually experiencing the problem. So they haven't been running without problems ..
2) Perhaps some units are better than others at maintaining their time settings and not drifting?
3) Maybe - like me - some people had actually manually added the relevant entries to the postcodes file?

Anyway - thanks again to everyone for the trouble-shooting. And hopefully that's goodbye to the clock-warping saga!!??

I can see Muzza is a happy camper! :D

Cheers

Mark

Quote:

---

Originally Posted by NZMarke

In reply to PetesTrash question "why have affected units been running without problems?" A couple of thoughts/points spring to mind :
1) I thought that mostly the people who had incorrect Postcode files WERE actually experiencing the problem. So they haven't been running without problems ..

---

According to Muzza's posts, both his and his in-law's TiVo were working fine, and only just started playing up.

Quote:

---

Originally Posted by NZMarke

2) Perhaps some units are better than others at maintaining their time settings and not drifting?

---

Not an issue, the timestamp file still needs to be updated to stop the TiVo recognising the timewarp and stopping the season passes from indexing. So, regardless of how well the TiVo actually keeps time, if you don't touch /var/timestamp the TiVo will recognise a timewarp.

Quote:

---

Originally Posted by NZMarke

3) Maybe - like me - some people had actually manually added the relevant entries to the postcodes file?

---

I imagine most people followed the NZ instructions :), but looking though the old posts the timezone file has been missing from the nztivo site since before August last year. So it would be a good idea for it to be re-attached.

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.

Glad to hear it's working.

Peter.

Quote:

---

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 :o

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.. :confused: Suggestions welcome.

Quote:

---

Originally Posted by DavidClarke

Not sure if it now needed or not.. :confused:

---

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.

Quote:

---

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

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??

Have you rebooted since updating the timezone file?

Peter.

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.

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)

No it looks fine.

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

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.

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.

Quote:

---

Originally Posted by Hoon

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.

---

I know it's a bit late, but for other people, make sure that there is no $ at the end of the Pacific/Auckland in the postcodezones file. In one of the earlier posts in this thread, there was a $ at the end of each line (due to cat -et). I used vi and recreated those and had the same lack of offset, until I removed the $ at the end of the line for my postcode.