Failed while preparing data.....AGAIN.

[Muzza]

Hi All

My TiVo is having guide data/season pass problems again. It usually occurs every few weeks and I force a re-index and it comes right again but this time round it isn't. Have been reading another link and trying their suggestions but just wondering if anyone in Kiwi-Land knows whats going on.

Refer...

http://forums.oztivo.net/showthread.php?t=1034

Any help would be much appreciated.
Ideally I don't want to re-image as I have too much stuff to lose.

Muzza

[NZMarke]

Hi Muzza -

Yes I've been periodically seeing the same thing. No guide data, and a message saying failed to prepare guide data when you do a daily call. Funnily enough I also got this message today.

Never used to get this problem before I reimaged 3-4 months back. Now I get it perhaps every 4 weeks or so.

Last time I think I fixed it by doing forcing an index - but I also followed that other thread and tried the things in there as well.

Anybody else seeing this problem?

Could it be there's something slightly odd in the guide data which throws things out or something .. and TiVo can't recover until you force an index?

He says ... grasping at straws! :rolleyes:
Mark

[DJC]

My unit has been running on the standard guide data for well over a year without a glitch... I've also used the NZ image since its release and that unit hasn't missed a beat since the day of install. ??

[Muzza]

My unit has been running on the standard guide data for well over a year without a glitch... I've also used the NZ image since its release and that unit hasn't missed a beat since the day of install. ??

Are you using the original 1.4 image?

[DJC]

1.3 and NZ(1.5) I believe.

I'd recommend giving the 1.5 based NZ image a go, it can't hurt and may help others who are in the same boat to know definitively if that is an answer.

[Muzza]

If I upgrade to the 1.5 image I will lose all my shows though. And there's a lot on there :eek:

[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.

[Muzza]

I still seem to be getting the Warped clock issue which is obviously preventing season passes and TiVo's recommendations working but since clearing all the data as suggested by NZMarke I have been able to get guide data no problem.

I run the timestamp and force index commands constantly and have restarted the TiVo and it never changes - it's really stating to do my head in! :mad:
I am desperately trying to watch everything currently on my TiVo and migrate some other stuff off via TYtools etc so that I can re-image my TiVo to 1.5.

Problem is.......my in-laws in Akl have just informed me their TiVo has just started showing the same symtoms as mine........damm.....I really need to find a solution that fixes the 1.4 image instead.

[petestrash]

I wouldn't blame the 1.4 image as there are hundreds of people in Oz using this image. It is strange that the only recent warped problems are occuring in NZ.

Are your inlaws using the same ISP as you are. Maybe some ISP's are blocking the NTP servers.

The servers used by ntpdate are all US servers:
129.6.15.29 US UNITED STATES MARYLAND GERMANTOWN NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY

192.43.244.18 US UNITED STATES COLORADO BOULDER NATIONAL CENTER FOR ATMOSPHERIC RESEARCH

129.6.15.29 US UNITED STATES MARYLAND GERMANTOWN NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY

try

ntpdate -b 129.6.15.29 from a telnet prompt and see what happens.

Peter.

[Muzza]

We are both with Xtra.

Results from suggestion....

[TiVo [p1] ~]# ntpdate -b 129.6.15.29
[TiVo [p1] ~]#
[TiVo [p1] ~]#

Is that what you'd expect or should I receive a confirmation or something?


Regards
Muzza.

[Hoon]

I've had the same problem every month since getting my tivo (about 3-4 months ago now). The only way I can get the guide data is by doing a clear & delete everything and running GS again. This is the only time for me that the daily call will work.

Once up and running my daily call will always fail again while preparing data and when my program guide data runs out I just do a clear and delete + GS again and that sees me right for another few weeks - very frustrating!!

I'm using the latest NZtivo image and my ISP is Xtra.

[Islander]

We are both with Xtra.

Results from suggestion....

[TiVo [p1] ~]# ntpdate -b 129.6.15.29
[TiVo [p1] ~]#
[TiVo [p1] ~]#

Is that what you'd expect or should I receive a confirmation or something?


Regards
Muzza.

I get:

[TiVo [S3]] # ntpdate -b 129.6.15.29
gmtime gives 106/4/28 11:43:45 [0]
sending to clock 06/05/28 11:43:45 [0]

My ISP is Xtra and I use the NZ version 1.4 and an OzTivo version (2 Tivos).
I have no problems with the loading of guide data.

Hope this helps.

[DJC]

Looks like Peter might be onto something here.

You should get this ... the response indicates that the ntp server has been successfully queried...

[TiVo [p1] ~]# ntpdate -b 129.6.15.29
gmtime gives 106/4/28 12:15:18 [0]
sending to clock 06/05/28 12:15:18 [0]
[TiVo [p1] ~]#
[TiVo [p1] ~]#
[TiVo [p1] ~]#

EDIT: As per Islander above. Also this means Xtra isn't likely doing anything funny with blocking. So the next step is to check your router configuration...

[DavidClarke]

similar issues to other users here, have made a cron script to touch the timestamp every am...

ntpdate -b 129.6.15.29 returns nothing, however I had its permissions wrong initially, but

[TiVo [p0] /bin]# rw
File system is now READ/WRITE.
[TiVo [p0] /bin]# chmod 755 /bin/ntpdate
[TiVo [p0] /bin]# ro

fixed that...

Anyone know a NTP server that is visiable from XTRA???

[DavidClarke]

Out of internest, ntp runs fine on my Mac on the same network (actually, both Macs), so NTP not seeing the world from my Tivo is an obvious problem and a likely source of the NZ warped clock issue.

Not sure why it works for some and not others. Too many variables to think about :confused:

[petestrash]

When you said NTP is running on your Mac's, were you using the same IP's as ntpdate uses?

Peter.

[Muzza]

What should I be checking on my router?

Just for interests sake - I have had my current router and Xtra connection for well over the last year so given this fault has only been more recently than that do you think Xtra has changed something or could it still be my router config?

Regards
Muzza.

[Wibble]

There is also an ntp server on Orac.
You can use orac.caffeine.co.nz or 210.48.107.133

That's ntp protocol, port 123, not the time protocol port 37.

See: http://forums.oztivo.net/showthread.php?t=631&highlight=ntpdate

[DavidClarke]

When you said NTP is running on your Mac's, were you using the same IP's as ntpdate uses?

Peter.

Peter, Yes, tried them all and a couple of NZ based NTP Servers as well from the Tivo. Also orac as per below, no dice from the tivo.

Thanks
Dave

[petestrash]

There is also an ntp server on Orac.
You can use orac.caffeine.co.nz or 210.48.107.133

That's ntp protocol, port 123, not the time protocol port 37.

See: http://forums.oztivo.net/showthread.php?t=631&highlight=ntpdate

I have tried using orac from here
[TiVo [p0] ~]# /bin/ntpdate -b 210.48.107.133, but it just hangs the process. From memory, I think orac blocks non NZ addresses so I can't test.

Also FYI the ntpdate used in r1.4 and r1.5 is no longer a symlink to fixtivotime. In fact fixtivotime is not included on recent images.

Peter.

[Wibble]

I think orac blocks non NZ addresses so I can't test.


It only used to block non-nz ftp addresses, so it should work.

You could try using Ethereal http://www.ethereal.com/
on you home machine and then try to do a ntpdate -b HOMEIP

You'll then see which protocol it uses and if it does get out of the tivo.

[Hoon]

I have managed to get my Tivo to load the guide data now after following the advice from this thread.
The nztivo image I have does not include fixtivotime or rtimetz so I had to download these. I also updated the ntpdate file (don't know whether this was necessary or not) as when I ran ntpdate all I got was the cursor i.e.

[TiVo [p1] ~]# ntpdate -b 129.6.15.29
[TiVo [p1] ~]#

The warptime fix and fixtivotime command seemed to do the trick for me. However I noticed that it wasn't picking up on my 02113 Pacific code so I copied over the Auckland and postcodezones files and ran again but it made no difference.
I also tried to put a manual entry into the postcodezones file for 02113 Pacific/Auckland. Fixtivotime now found 02113 but my clock was now 12hrs out (not applying the GMT+12) so I undid it all and set my timezone to GMT+12.

[petestrash]

It only used to block non-nz ftp addresses, so it should work.

You could try using Ethereal http://www.ethereal.com/
on you home machine and then try to do a ntpdate -b HOMEIP

You'll then see which protocol it uses and if it does get out of the tivo.

The current ntpdate uses port 37.

Peter.

[petestrash]

I noticed that it wasn't picking up on my 02113 Pacific code so I copied over the Auckland and postcodezones files and ran again but it made no difference.
I also tried to put a manual entry into the postcodezones file for 02113 Pacific/Auckland. Fixtivotime now found 02113 but my clock was now 12hrs out (not applying the GMT+12) so I undid it all and set my timezone to GMT+12.

if you want to see what tz you have set try
[TiVo [p0] ~]# /bin/ntpdate -v
Our postcode is 06000. Found matching timezone Australia/Perth
Offset 28800 for timezone WST, daylight saving is 0
Failed to connect to any of the time servers

Peter.

[Wibble]

The current ntpdate uses port 37.
Peter.

Ok, I set up Orac to also have port 37 open (tcp and udp) . And I've seen some
traffic on tcp 37.

So if people want to try /bin/ntpdate -b 210.48.107.133 again.

If that doesn't work, try
/bin/ntpdate -bu 210.48.107.133

the -u nmake ntpdate use an unpriviledged source port, which apparently has helped some people.

[Muzza]

Hi All

Without sounding like a complete moron I am kind of lost as to what I should actually be doing with my time issue. I have been reading through the various posts but am getting confused and now I am back at "failed while preparing data" again.

In a nutshell......

I have 2 TiVos running the 1.4 image (1 is at the in-laws). Neither network/internet connection/router or ISP have changed since we have had the 1.4 image. Everything used to be working fine and then a few months back I got the "warped clock" issue. The first few times this occured though was able to be fixed by the timestamp & force index commands.

A couple of weeks ago though when it happened I couldn't fix it untill I cleared all guide data from the TiVo and downloaded it from scratch again. This fixed the gudie data but my season passes etc haven't worked for quite some (presumably because when I look at the logs the warped clock issue never came right). After downloading data again for the last week though it has stopped again.

I don't get the expected reply from any of the ntpdate commands (It just jumps back to the standard prompt as mentioned in earlier posts).

This is getting very frustrating and probably mainly due to my lack of knowledge editing the image etc it would appear.

My in-laws TiVo has only suddenly gone down the same path as mine this week after working fine for months.

What should I be doing (in nice basic steps :o please).

Appreciated
Muzza.

[Wibble]

What should I be doing (in nice basic steps :o please).

Appreciated
Muzza.

I'd like to help, but I'm currently running 1.3, so I can't replicate the problem.

You could try the following and post the output

ntpdate -b -ddd 210.48.107.133

if that doesn't work

ntpdate -bu -ddd 210.48.107.133

This should turn all the debugging on and we can work out what it's doing.

If somebody with a working 1.4 could do the same that would be great.

[petestrash]

Ok, I set up Orac to also have port 37 open (tcp and udp) . And I've seen some
traffic on tcp 37.

So if people want to try /bin/ntpdate -b 210.48.107.133 again

I can confirm orac works for me now. Could someone with troubles (using extra) try and see if it works for them.

Peter.

[petestrash]

You could try the following and post the output

ntpdate -b -ddd 210.48.107.133

if that doesn't work

ntpdate -bu -ddd 210.48.107.133


Those commands won't work with this version of ntpdate, the only syntax is ntpdate [-B] [-b] [d] [-q] [-v] server [server ...]

But Muzza should try /bin/ntpdate -b 210.48.107.133 and see if it works any better than the other servers.

Peter.

[Muzza]

Here's my results......

[TiVo [p0] ~]# ntpdate -b -ddd 210.48.107.133
[TiVo [p0] ~]#
[TiVo [p0] ~]# ntpdate -bu -ddd 210.48.107.133
ntpdate: invalid option -- u
[TiVo [p0] ~]#

and.....

[TiVo [p0] ~]# /bin/ntpdate -b 210.48.107.133
[TiVo [p0] ~]#
[TiVo [p0] ~]#

Not very helpful is it. :(

[DJC]

Not very helpful is it. :(

It is helpful in the fact that you now know what is causing or contributing to the clock warped issue.

When the rest of us access the emulator, our tivo clocks are automatically set to the correct time (daily). No drift and no warped clock.

Can you sum your ntpdate and post the result here, better check just in case

type:-

sum /bin/ntpdate

[Wibble]

try ntpdate -v -v -v -s 210.48.107.133
or ntpdate -vvvs 210.48.107.133
if that works make the one you use ntpdate -s 210.48.107.133

There are 2 version of ntpdate.

The one where this works:
ntpdate -ddd 127.0.0.1
31 May 10:47:41 ntpdate[399]: ntpdate 3-5.93 Fri Apr 5 00:15:50 PST 2002 (1)
which uses UDP port 123

and the version which is the one you appear to have
which uses TCP port 37

For those that are interested, the
UDP 123 version of ntp date is based on this:
http://www.opensource.apple.com/darwinsource/10.3.7/ntp-16/ntp/ntpdate/ntpdate.c

The TCP 37 source is here:
http://www.forums.oztivo.net/showthread.php?p=2295&#post2295

[petestrash]

try ntpdate -v -v -v -s 210.48.107.133
or ntpdate -vvvs 210.48.107.133
if that works make the one you use ntpdate -s 210.48.107.133


FWIW on my system using the current (port37) OzTiVo ntpdate I get the following


[TiVo [p0] ~]# /bin/ntpdate -v -v -v -s 210.48.107.133
/bin/ntpdate: invalid option -- s
Our postcode is 06000. Found matching timezone Australia/Perth
Offset 28800 for timezone WST, daylight saving is 0
Connecting to time server 210.48.107.133
Setting the local time to Wed May 31 11:21:09 2006
gmtime gives 106/4/31 11:21:09 [3]
sending to clock 06/05/31 11:21:09 [3]
[TiVo [p0] ~]#
[TiVo [p0] ~]# /bin/ntpdate -vvvs 210.48.107.133
/bin/ntpdate: invalid option -- s
Our postcode is 06000. Found matching timezone Australia/Perth
Offset 28800 for timezone WST, daylight saving is 0
Connecting to time server 210.48.107.133
Setting the local time to Wed May 31 11:21:37 2006
gmtime gives 106/4/31 11:21:37 [3]
sending to clock 06/05/31 11:21:37 [3]


Which is the same result as just using a single verbose -v.

and the sum is:
[TiVo [p0] ~]# sum /bin/ntpdate
25904 59


Peter.

[DavidClarke]

XTRA... FWIW

[TiVo [p3] ~]#
[TiVo [p3] ~]# ntpdate -v -v -v -s 210.48.107.133
ntpdate: invalid option -- s
Our postcode is 02113. No matching timezone for postcode 02113
[TiVo [p3] ~]#
[TiVo [p3] ~]#
[TiVo [p3] ~]# ntpdate -vvvs 210.48.107.133
ntpdate: invalid option -- s
Our postcode is 02113. No matching timezone for postcode 02113
[TiVo [p3] ~]#
[TiVo [p3] ~]# sum /bin/ntpdate
25904 59
[TiVo [p3] ~]#

[Muzza]

It is helpful in the fact that you now know what is causing or contributing to the clock warped issue.

When the rest of us access the emulator, our tivo clocks are automatically set to the correct time (daily). No drift and no warped clock.

Can you sum your ntpdate and post the result here, better check just in case

type:-

sum /bin/ntpdate

My result....

[TiVo [p1] ~]# sum /bin/ntpdate
25904 59
[TiVo [p1] ~]#
[TiVo [p1] ~]#

[Muzza]

try ntpdate -v -v -v -s 210.48.107.133
or ntpdate -vvvs 210.48.107.133
if that works make the one you use ntpdate -s 210.48.107.133

There are 2 version of ntpdate.

The one where this works:
ntpdate -ddd 127.0.0.1
31 May 10:47:41 ntpdate[399]: ntpdate 3-5.93 Fri Apr 5 00:15:50 PST 2002 (1)
which uses UDP port 123

and the version which is the one you appear to have
which uses TCP port 37

For those that are interested, the
UDP 123 version of ntp date is based on this:
http://www.opensource.apple.com/darwinsource/10.3.7/ntp-16/ntp/ntpdate/ntpdate.c

The TCP 37 source is here:
http://www.forums.oztivo.net/showthread.php?p=2295&#post2295

My result......

[TiVo [p1] ~]# ntpdate -v -v -v -s 210.48.107.133
ntpdate: invalid option -- s
Our postcode is 02113. No matching timezone for postcode 02113
[TiVo [p1] ~]#
[TiVo [p1] ~]# ntpdate -vvvs 210.48.107.133
ntpdate: invalid option -- s
Our postcode is 02113. No matching timezone for postcode 02113
[TiVo [p1] ~]#
[TiVo [p1] ~]#

[DJC]

OK so the ntpdates are all correct. So thats not the issue, the image is ok.

Please post your /etc/postcodezones file... type:-

cat /etc/postcodezones

You need to check two things.

1. There is only one tab between the postcode and timezone

2. The file is in unix format (that there are no ^M's) ...

[thomson]

[TiVo [p3] ~]# ntpdate -vvvs 210.48.107.133
ntpdate: invalid option -- s
Our postcode is 02113. No matching timezone for postcode 02113

DJC is correct. It looks like you may not have an entry in your /etc/postcodezones file. If you execute "cat -et /etc/postcodezones" then you should see a line similar to:

02113^IPacific/Auckland$

[DavidClarke]

OK so the ntpdates are all correct. So thats not the issue, the image is ok.

Please post your /etc/postcodezones file... type:-

cat /etc/postcodezones

You need to check two things.

1. There is only one tab between the postcode and timezone

2. The file is in unix format (that there are no ^M's) ...

[TiVo [p3] ~]# cat /etc/postcodezones
# A list of TiVo postcodes and the timezones that they represent
# Two columns, separated by one tab only.
#
00800 Australia/Darwin
02000 Australia/Sydney
02600 Australia/Sydney
03000 Australia/Melbourne
04000 Australia/Brisbane
05000 Australia/Adelaide
06000 Australia/Perth
07000 Australia/Hobart
[TiVo [p3] ~]#

Who nicked Godzone off the list? :D

[DJC]

Ok, thats your problem you need the New Zealand postcodes in this file.

This is in the NZ images, but perhaps not in the earlier AU images..

This is my file and the standard file I've included in the NZ images.

Ensure you use 1 tab between the zone and the 'Pacific/Auckland'



# A list of TiVo postcodes and the timezones that they represent
# Two columns, separated by one tab only.
#
00800 Australia/Darwin
02000 Australia/Sydney
02600 Australia/Sydney
03000 Australia/Melbourne
04000 Australia/Brisbane
05000 Australia/Adelaide
06000 Australia/Perth
07000 Australia/Hobart
64000 Pacific/Auckland

# New Zealand
02112 Pacific/Auckland
02113 Pacific/Auckland
02114 Pacific/Auckland
02115 Pacific/Auckland
02116 Pacific/Auckland


Set that up and post results thanks.

[Muzza]

OK so the ntpdates are all correct. So thats not the issue, the image is ok.

Please post your /etc/postcodezones file... type:-

cat /etc/postcodezones

You need to check two things.

1. There is only one tab between the postcode and timezone

2. The file is in unix format (that there are no ^M's) ...

[TiVo [p1] ~]# cat /etc/postcodezones
# A list of TiVo postcodes and the timezones that they represent
# Two columns, separated by one tab only.
#
00800 Australia/Darwin
02000 Australia/Sydney
02600 Australia/Sydney
03000 Australia/Melbourne
04000 Australia/Brisbane
05000 Australia/Adelaide
06000 Australia/Perth
07000 Australia/Hobart
[TiVo [p1] ~]#
[TiVo [p1] ~]#

[Muzza]

DJC is correct. It looks like you may not have an entry in your /etc/postcodezones file. If you execute "cat -et /etc/postcodezones" then you should see a line similar to:

02113^IPacific/Auckland$

[TiVo [p1] ~]# 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$
[TiVo [p1] ~]#

[DJC]

Same goes for you Muzza, please add the NZ specific lines and post your results...

[Muzza]

Ok, thats your problem you need the New Zealand postcodes in this file.

This is in the NZ images, but perhaps not in the earlier AU images..

This is my file and the standard file I've included in the NZ images.

Ensure you use 1 tab between the zone and the 'Pacific/Auckland'



# A list of TiVo postcodes and the timezones that they represent
# Two columns, separated by one tab only.
#
00800 Australia/Darwin
02000 Australia/Sydney
02600 Australia/Sydney
03000 Australia/Melbourne
04000 Australia/Brisbane
05000 Australia/Adelaide
06000 Australia/Perth
07000 Australia/Hobart
64000 Pacific/Auckland

# New Zealand
02112 Pacific/Auckland
02113 Pacific/Auckland
02114 Pacific/Auckland
02115 Pacific/Auckland
02116 Pacific/Auckland


Set that up and post results thanks.

Sorry again for being dumb, again, but how do "I set that up"? :confused:

[DJC]

Edit the file with vi or joe whichever you feel comfortable in. If your've never used vi, use joe.

joe /etc/postcodezones

Add the missing lines (type em in).

EDIT:Alternatively, grab the master postcodezones file from orac ftp://orac.caffeine.co.nz/install/postcodezones (ftp://orac.caffeine.co.nz/install/postcodezones)in the install directory of the ftp site, then ftp it directly to your tivo. This is the file used in the NZ customised images.

[DavidClarke]

Ok, thats your problem you need the New Zealand postcodes in this file.


[TiVo [p3] ~]# cat /etc/postcodezones
# A list of TiVo postcodes and the timezones that they represent
# Two columns, separated by one tab only.
#
00800 Australia/Darwin
02000 Australia/Sydney
02600 Australia/Sydney
03000 Australia/Melbourne
04000 Australia/Brisbane
05000 Australia/Adelaide
06000 Australia/Perth
07000 Australia/Hobart

# New Zealand
02112 Pacific/Auckland
02113 Pacific/Auckland
02114 Pacific/Auckland
02115 Pacific/Auckland
02116 Pacific/Auckland
[TiVo [p3] ~]#

[TiVo [p3] ~]# /bin/ntpdate -v -v -v -s 210.48.107.133
/bin/ntpdate: invalid option -- s
Our postcode is 02113. No matching timezone for postcode 02113
[TiVo [p3] ~]#

Hmmmm, progress, but....

[DJC]

Hmmmm, progress, but....

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

cat -et /etc/postcodezones

[Muzza]

Edit the file with vi or joe whichever you feel comfortable in. If your've never used vi, use joe.

joe /etc/postcodezones

Add the missing lines (type em in).



Thanks DJC - Understand that :o

Done. And now shows....

[TiVo [p1] ~]# cat /etc/postcodezones

# A list of TiVo postcodes and the timezones that they represent
# Two columns, separated by one tab only.
#
00800 Australia/Darwin
02000 Australia/Sydney
02600 Australia/Sydney
03000 Australia/Melbourne
04000 Australia/Brisbane
05000 Australia/Adelaide
06000 Australia/Perth
07000 Australia/Hobart
64000 Pacific/Auckland

# New Zealand
02112 Pacific/Auckland
02113 Pacific/Auckland
02114 Pacific/Auckland
02115 Pacific/Auckland
02116 Pacific/Auckland
[TiVo [p1] ~]#

[Muzza]

This would be a good sign wouldn't it........

[TiVo [p1] ~]# /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:27:54 2006
gmtime gives 106/4/31 20:27:54 [3]
sending to clock 06/05/31 20:27:54 [3]
[TiVo [p1] ~]#

:D

[DJC]

Thanks DJC - Understand that :o

Done. And now shows....



And the ntpdate output just use the -v flag

ntpdate -v 210.48.107.133

is sufficient

[DavidClarke]

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

[DavidClarke]

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!:) :) :)

[Muzza]

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

[DJC]

Welcome.

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

Cheers/DJC

[DavidClarke]

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

[DJC]

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.

[petestrash]

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.

[Muzza]

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

[NZMarke]

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

[petestrash]

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.


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.


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.

[DavidClarke]

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.

[petestrash]

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:


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]

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:


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]

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]

Have you rebooted since updating the timezone file?

Peter.

[Hoon]

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]

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]

No it looks fine.

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

[petestrash]

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]

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.

[DOlsen]

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.