Tivo Philips Series 1 - Unable to get updates from oztivo.net

[PeterCathery]

Hi all,
I know this is an old thread, however it is the closest description to the issues I have. I dont seem to be able to receive any data downloads onto my TIVO. I have performed several of the suggestions in various FAQ's and forums.
Mine is a Tivo Philips Series 1 that was handed down to me from a mate who has upgraded to the latest one. This unit had been laying idle for several months and when I fired it up, the TV Guide data was well out of date.
Everything seems to work OK on it with the exception that I cannot get the TV Guide info to load from oztivo.net. The build is 1.6.2 and the Tivo config files all seem to have the correct information according to what has been suggested to resolve such issues, but clearly I'm missing something.
I'm connecting through my ISP Bigpond Cable connection via a router and local pings work fine in all directions. ie., Using Telnet, Tivo to Router (192.168.1.254), & Cable Modem (192.168.100.1). In addition to this, I can connect via my browser to the Tivo using TivoWebPlus (ver 1.3.1), so I feel fairly confident that there is nothing blocking the local network data flow.
To ensure that there are no blockers to the Tivo unit, I have set my Tivo up through my router's DMZ, so it has direct access onto the web. Pings to time server (132.163.4.103) and oztivo (65.49.60.197) confirm that I can reach outside destinations OK. However both 'ntupdate' and any attempts to retrieve TV Guides from the same IP's, fail. :o

Any assistance would be appreciated.

Regards
Peter C

Here are the results from ntupdate and the ping to the IP's above.

===============
[TiVo [p0] ~]# ntpdate -bv 132.163.4.103
oztivo ntpdate $Revision: 1.21 $
Our postcode is 03000. Found matching timezone Australia/Melbourne
Offset 36000 for timezone EST, daylight saving is 0
Connecting to time server 132.163.4.103
TIMEOUT!
Failed to connect to 132.163.4.103: Interrupted system call
Failed to connect to any of the time servers
[TiVo [p0] ~]#
[TiVo [p0] ~]# ping 132.163.4.103
PING 132.163.4.103 (132.163.4.103): 56 data bytes
64 bytes from 132.163.4.103: icmp_seq=0 ttl=48 time=233.4 ms
64 bytes from 132.163.4.103: icmp_seq=1 ttl=48 time=234.4 ms
64 bytes from 132.163.4.103: icmp_seq=2 ttl=48 time=232.4 ms
64 bytes from 132.163.4.103: icmp_seq=3 ttl=48 time=232.9 ms
64 bytes from 132.163.4.103: icmp_seq=4 ttl=48 time=234.0 ms
64 bytes from 132.163.4.103: icmp_seq=5 ttl=48 time=233.7 ms
64 bytes from 132.163.4.103: icmp_seq=6 ttl=48 time=234.3 ms
64 bytes from 132.163.4.103: icmp_seq=7 ttl=48 time=233.9 ms
64 bytes from 132.163.4.103: icmp_seq=8 ttl=48 time=234.4 ms
64 bytes from 132.163.4.103: icmp_seq=9 ttl=48 time=233.8 ms
64 bytes from 132.163.4.103: icmp_seq=10 ttl=48 time=234.2 ms
64 bytes from 132.163.4.103: icmp_seq=11 ttl=48 time=234.2 ms
64 bytes from 132.163.4.103: icmp_seq=12 ttl=48 time=234.0 ms

--- 132.163.4.103 ping statistics ---
13 packets transmitted, 13 packets received, 0% packet loss
round-trip min/avg/max = 232.4/233.8/234.4 ms
[TiVo [p0] ~]#
[TiVo [p0] ~]#
[TiVo [p0] ~]# ping 65.49.60.197
PING 65.49.60.197 (65.49.60.197): 56 data bytes
64 bytes from 65.49.60.197: icmp_seq=0 ttl=49 time=177.0 ms
64 bytes from 65.49.60.197: icmp_seq=1 ttl=49 time=176.6 ms
64 bytes from 65.49.60.197: icmp_seq=2 ttl=49 time=176.5 ms
64 bytes from 65.49.60.197: icmp_seq=3 ttl=49 time=176.6 ms
64 bytes from 65.49.60.197: icmp_seq=4 ttl=49 time=176.5 ms
64 bytes from 65.49.60.197: icmp_seq=5 ttl=49 time=177.1 ms

--- 65.49.60.197 ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 176.5/176.7/177.1 ms
[TiVo [p0] ~]#
[TiVo [p0] ~]#

[petestrash]

I have moved your Post to a new thread.

It really is not worth tacking a new post on to a thread over a year old.

It is better to start a new one if there have been no posts for a couple of months.

You can always make a note in your post about what you have read in a similar thread.

I suspect your problem is that your ISP (assuming TiVo is in DMZ as you have said) is blocking time (port 37 tcp/udp).

Also can you try
ps ax | grep emu*

Peter.

[PeterCathery]

Hi Peter, as requested.

[TiVo [p0] ~]# ps ax | grep emu*
181 ? SW 0:00 /hack/bin/emuProxyZA -s www.oztivo.net -p 9090
231 p0 SW 0:00 grep emu*
[TiVo [p0] ~]#

Regards Peter

[petestrash]

Ok, since you have emuProxyZA running, we might be able to get around your ISP's port block by adding a line to the conf file.

Enter the following commands (in red) at the putty prompt:

[TiVo [p0] ~0]# rw
[TiVo [p0] ~0]# echo "ntpIP=132.163.4.103" >> /var/hack/etc/emuProxyZA.conf
[TiVo [p0] ~0]# echo "132.163.4.103" > /etc/ntpdate_local_ip
[TiVo [p0] ~0]# ro
[TiVo [p0] ~0]# reboot

Once your TiVo is rebooting, you can close putty.

Once back up, try the ntpdate command again and then paste the results here.

Peter.

PS who is your ISP.

[PeterCathery]

Hi Peter, as requested. Still no joy after rebooting.

================================
[TiVo [p0] ~]# ntpdate -bv 132.163.4.103
oztivo ntpdate $Revision: 1.21 $
Locally configured IP address: 132.163.4.103
Our postcode is 03000. Found matching timezone Australia/Melbourne
Offset 36000 for timezone EST, daylight saving is 0
Connecting to time server 132.163.4.103
TIMEOUT!
Failed to connect to 132.163.4.103: Interrupted system call
Connecting to time server 132.163.4.103
TIMEOUT!
Failed to connect to 132.163.4.103: Interrupted system call
Failed to connect to any of the time servers
[TiVo [p0] ~]#
[TiVo [p0] ~]#
==================================


Pings still good to the time server.
ie.,[TiVo [p0] ~]# ping -c 10 132.163.4.103

PING 132.163.4.103 (132.163.4.103): 56 data bytes
64 bytes from 132.163.4.103: icmp_seq=0 ttl=48 time=243.9 ms
64 bytes from 132.163.4.103: icmp_seq=1 ttl=48 time=236.0 ms
64 bytes from 132.163.4.103: icmp_seq=2 ttl=48 time=233.6 ms
64 bytes from 132.163.4.103: icmp_seq=3 ttl=48 time=233.9 ms
64 bytes from 132.163.4.103: icmp_seq=4 ttl=48 time=235.2 ms
64 bytes from 132.163.4.103: icmp_seq=5 ttl=48 time=233.1 ms
64 bytes from 132.163.4.103: icmp_seq=6 ttl=48 time=232.3 ms
64 bytes from 132.163.4.103: icmp_seq=7 ttl=48 time=233.9 ms
64 bytes from 132.163.4.103: icmp_seq=8 ttl=48 time=233.2 ms
64 bytes from 132.163.4.103: icmp_seq=9 ttl=48 time=232.0 ms

--- 132.163.4.103 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 232.0/234.7/243.9 ms
[TiVo [p0] ~]#
[TiVo [p0] ~]#

Was I supposed to see a response when I typed the commands you suggested. Here is what I saw from Putty.

==================================
[TiVo [p0] ~]# rw
File system is now READ/WRITE.
[TiVo [p0] ~]#
[TiVo [p0] ~]# echo "ntpIP=132.163.4.103" >> /var/hack/etc/emuProxyZA.conf
[TiVo [p0] ~]#
[TiVo [p0] ~]# echo "132.163.4.103" > /etc/ntpdate_local_ip
[TiVo [p0] ~]#
[TiVo [p0] ~]# ro
File system is now READ ONLY.
[TiVo [p0] ~]#
[TiVo [p0] ~]# reboot
=================

Regards Peter C :(

[petestrash]

Who is your ISP?

Have you asked them to open port 37?

Peter.

[PeterCathery]

Sorry Peter,
I meant to answer your question before. I'm with BigPond via a Cable Modem ie., connected via the Telstra HFC. Do you know if there are any other Tivo members who are also using BigPond Cable as their ISP ? I don't know if they do block Port 37 tcp/udp but I can find out.
I have attached a couple of logs generated after the reboot. I don't know what to look for in these logs, but there are a couple of lines that indicate some type of error.

Thanks for your assistance.

Regards Peter c

[petestrash]

Others are using Telstra Cable, but their policies are not consistent Australia wide.

Your logs look normal so far. Force a call and post your tclient log again.

Peter.

[PeterCathery]

Hi Peter, I have attached tclient data, after a reboot as requested.
Regards
Peter C

[petestrash]

Some thing appears to be corrupted in your MFS as it believes setup has not been completed.

May 12 22:26:37 (none) tcphonehome[166]: getting /State/GeneralConfig/Complete
May 12 22:26:37 (none) tcphonehome[166]: Setup not finished, skipping call

The only way around this is re-do guided setup.

Peter.