Daily call not working

[MelissaH]

Hi there,
Help please! I have a new tivo and the daily call won't work. I got it from Darren King (thanks!) and it worked for him, but i haven't been able to get it to make any daily calls.

I have followed the instructions on the Networking How To diagnostics and ifconfig, route, ping and dial prefix work, but wget fails - i get this:

[TiVo [p1] ~]# wget http://131.244.9.101/index.html
--20:22:54-- http://131.244.9.101/index.html
=> `index.html.4'
Connecting to 131.244.9.101:80...

The tclient log from my last attempt is attached.

Any help would be most appreciated!

Cheers,
Melissa.

[petestrash]

Your TiVo's IP is 192.168.0.10

What is the internet address of your router

Your TiVo is timing out both during the wget you tried and during the daily call

Peter.

PS minnie is appears to be down at the moment. so daily calls and wgets won't work.

[MelissaH]

Hi Peter,
The IP of the router is 192.168.0.1

When i tried it all a week ago the wget was fine, but still no daily call.

Melissa.

[petestrash]

Ok, at least both the TiVo and router are on the same subnet.

Does wget fail for you right now?

could you post the results of your 'route' test and the contents of your /etc/oztivo.conf file.

Peter.

[MelissaH]

Wget is still timing out

[TiVo [p1] ~]# route
route_info, afname=inet, options=33
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 * 255.255.255.0 U 32767 0 0 eth0
default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0

# OzTiVo menu configuration settings file
# Please do not edit this file
# Run the nic_config_tivo tool to reconfigure
nic=TurboNet
ip=192.168.0.10
mac=00:0B:AD:72:47:36
timing=3
hostname=oztivo
emulator=minnie.tuhs.org
emulatorport=80
netmask=255.255.255.0
gateway=192.168.0.1
ssid=
wep=
wepkey=

Cheers,
Melissa.

[Wibble]

Wget is still timing out


Could you try the following:

wget http://210.48.107.133:8000

then

wget http://210.48.107.133:80

If the 1st works but not the second, it's probably a proxy problem at your ISP.

Also can you post the output of:

traceroute -n 131.244.9.101

[Darren King]

It may be worth mentioning that you are trying to use a wireless adaptor on a Turbonet card too.

[petestrash]

It may be worth mentioning that you are trying to use a wireless adaptor on a Turbonet card too.

In that case it may be worth plugging your TiVo directly into the router to rule out the Wireless portion. You don't need to have any other connections in the TiVo, just power and network to test this.

Peter.

[MelissaH]

The Tivo is now plugged directly into the router and the results are:

[TiVo [p1] ~]# wget http://210.48.107.133:8000
--16:42:22-- http://210.48.107.133:8000/
=> `index.html.6'
Connecting to 210.48.107.133:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1,858 [text/html]

0% [ ] 1,858 0.00B/s ETA 00:00

Last-modified header invalid -- time-stamp ignored.
16:42:22 (0.00 GB/s) - `index.html.6' saved [1858/1858]


[TiVo [p1] ~]# wget http://210.48.107.133:80
--16:42:46-- http://210.48.107.133/
=> `index.html.7'
Connecting to 210.48.107.133:80...

[TiVo [p2] ~]# traceroute -n 131.244.9.101
traceroute to 131.244.9.101 (131.244.9.101), 30 hops max, 40 byte packets
1 192.168.0.1 1.929 ms 1.148 ms 0.990 ms
2 203.17.101.67 17.147 ms 16.603 ms 15.794 ms
3 203.10.110.195 16.234 ms 15.648 ms 16.053 ms
4 * 203.166.93.197 15.461 ms 19.244 ms
5 210.80.33.157 17.748 ms 16.003 ms 15.536 ms
6 210.80.32.34 15.970 ms 15.573 ms 16.039 ms
7 202.139.39.253 19.456 ms 15.114 ms 16.714 ms
8 202.139.124.86 45.917 ms 48.597 ms 49.192 ms
9 59.154.4.2 47.126 ms 45.791 ms 45.266 ms
10 203.13.70.25 53.954 ms 56.301 ms 55.108 ms
11 203.144.10.94 51.654 ms 175.484 ms 115.739 ms
12 192.48.109.2 134.035 ms 188.031 ms 195.143 ms
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *

Thanks,
Melissa.

[Wibble]

Ok, your networking setup is working fine and you get sucessfully to to port 8000 on a remote server.

But you cannot get to port 80 on a remote server (which is what you need for the daily call).

This is usually caused by your ISP's proxy (or possibly but unlikely by your router setup)
I'm assuming you can get to http://minnie.tuhs.org/ from you computer.

I believe the workaround is to use the emuproxy, but I would have thought you were already using it. (This is outside my knowledge area).
Could you copy any lines from /etc/tclient.conf which doesn't start with a #
Should be something like
127::127.0.0.1:8000:::

and any line in rc.sysinit.author which start with emuProxy

Somebody who knows the Oztivo emulator setup should be able to help you.
(I'm in NZ)

[MelissaH]

Yes i can access http://minnie.tuhs.org/

Hope the info below helps.. :-)
Melissa.

/etc/tclient.conf

000:
# Dennis' Emulator
126::66.23.218.193:80:::
# This is for the server emulator on minnie. Trouble if your ISP blocks HTTP .9
#127::131.244.9.101:80:::

# This uses emuProxy2 to avoid problems with transparent proxy. Thanks Tim!
127::127.0.0.1:8000:::

rc.sysinit.author
# Emu Proxy
# A tool for cleaning up the HTTP output by the Tivo in order to pass through
# transparent proxies, etc.
# Works in conjunction with a small hack to the emulator to accept the header
# "TivoURLBase" which is the base url to give back to the Tivo when specifying
# data paths.
# Runs by default and is dependent on the
# 127::127.0.0.1:8000:::
# entry in tclient.conf
# IF YOU COMMENT THIS OUT SO IT DOESN'T RUN, YOU MUST EDIT THE "127" entry
# in /etc/tclient.conf to reflect the IP and port of the emulator you are using
# There is a backup of the original here: /etc/tclient.conf-oztivo

if checkyesno emuproxy_enable; then
if [ "$emuproxy_version" = "2" ]; then
# Run emuProxy2
# Usage: %s [-d] [-h] [-l localport] [-L listenAddr] [-s serverip]
# [-p serverport]
/hack/bin/emuProxy2 -s 131.244.9.101 -p $emulatorport &
fi

if [ "$emuproxy_version" = "3" ]; then
# Run emuProxy3
# Usage: %s [-d] [-h] [-l localport] [-L listenAddr] [-s serverip]
# [-p serverport]
/hack/bin/emuProxy3 -s 131.244.9.101 -p $emulatorport &
fi

if [ "$emuproxy_version" = "ZA" ]; then
# Run emuProxyZA
# You can change the emulator name/port in /etc/oztivo.conf
# For other config changes, do them in /hack/etc/emuProxyZA.conf
/hack/bin/emuProxyZA -s $emulator -p $emulatorport &
fi
fi

[petestrash]

I agree with wibble and your tclient.conf shows that you should be already using one of the emuproxys.

Try 'ps ax | grep Proxy' without the quotes to see which proxy is loaded

Also also show the contents of your /etc/sysinit.conf (if it exists).

If it doesn't exist, then show your /etc/dflt_sysinit.conf file.

Which ISP are you with?

Peter.

[MelissaH]

I'm with Netspace.

[TiVo [p0] ~]# ps ax | grep Proxy
164 ? S 0:00 /hack/bin/emuProxyZA -s minnie.tuhs.org -p 80
268 p0 SW 0:00 grep Proxy

There wasn't /etc/sysinit.conf, but here's /etc/dflt_sysinit.conf :

Thanks, Melissa.

# Parameters controlling rc.sysinit.author
ccxstream_enable="NO" # Start ccxstream
cron_enable="YES" # Start cron
tivoftpd_enable="YES" # Start tivoftpd
tivoweb_enable="YES" # Start TivoWeb or TivoWebPlus:
tivoweb_version="PLUS" # Set to "" for TivoWeb, or "PLUS"
autospace_enable="YES" # Start Autospace
vserver_enable="NO" # Start vserver
endpad_enable="YES" # Start endpad
copymod_enable="NO" # Install /lib/modules/copy.o
emuproxy_enable="YES" # Start one of the emuproxy programs:
emuproxy_version="ZA" # Either "2", "3" or "ZA"
report_ip_enable="YES" # Report the IP address at boot time
trickey_enable="YES" # Start trickey
k9tivo_enable="NO" # Start k9tivo ntp client
bufferhack_enable="NO" # Start bufferhack
bufferhack_size="60" # 60 minute bufferhack buffer size

#
# Functions used by the rc.sysinit scripts
# DON'T CHANGE ANYTHING BELOW THIS LINE!
#
# checkyesno var
# Test $1 variable, and warn if not set to YES or NO.
# Return 0 if it's "yes" (et al), nonzero otherwise.
# Borrowed from FreeBSD 6.x.
#
checkyesno()
{
eval _value=\$${1}
#debug "checkyesno: $1 is set to $_value."
case $_value in

# "yes", "true", "on", or "1"
[Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|[Oo][Nn]|1)
return 0
;;

# "no", "false", "off", or "0"
[Nn][Oo]|[Ff][Aa][Ll][Ss][Ee]|[Oo][Ff][Ff]|0)
return 1
;;
*)
echo "Warning: ${1} is not set properly - see /etc/dflt_sysinit.conf"
return 1
;;
esac
}

[petestrash]

Ok, emuProxyZA is running correctly.

Did you try a call home while the TiVo was directly connected to your router?

Peter

[MelissaH]

Yes i did and got the same result, timing out. Any other suggestions out there?!

Many thanks,
Melissa.

[Darren King]

Well I can say it is not TiVo hardware at fault. You either get something or nothing at all. Given you can at least send and receive commands via Telnet and TiVoWEB means you have got the hardware talking.

I didn't set anything out of the ordinary when setting up the image and the initial setup and testing did work. Given such unless something has gone wayward since handing over I know that Netspace should not have any proxy issues which only leaves local settings or the modem/router with an issue.

[MattCallow]

Have you established that DNS is working on your tivo? Can you try


ping -c 1 minnie.tuhs.org
You should see something like

PING minnie (131.244.9.101): 56 data bytes

--- minnie ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

Which means that the Tivo can resolve the hostname OK.
Now, to check that emuproxy is listening on the right port, type:

netstat -atn
You should see a line like:

tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN
Now see if you can access minnie directly, and then with the proxy. Try:

wget -v http://minnie.tuhs.org -O direct_test.html
and

wget -v http://localhost:8000 -O proxy_test.html
Now check the files saved by wget:

ls -l *test.html
You should get something like:

-rw-r--r-- 1 0 0 7388 Feb 28 17:45 direct_test.html
-rw-r--r-- 1 0 0 7388 Feb 28 17:42 proxy_test.html

Then post all your results here.

[MelissaH]

ok, thanks everyone, here's the results....

[TiVo [p0] ~]# ping -c 1 minnie.tuhs.org
PING minnie (131.244.9.101): 56 data bytes

--- minnie ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

[TiVo [p0] ~]# netstat -atn
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 14476 127.0.0.1:1026 127.0.0.1:8000 FIN_WAIT1
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN
tcp 0 130 192.168.0.10:23 192.168.0.2:1165 ESTABLISHED
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN
tcp 17294 0 127.0.0.1:8000 127.0.0.1:1026 ESTABLISHED
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN
tcp 1 0 192.168.0.10:80 192.168.
tcp 1 0 192.168.0.10:80 192.168.0.2:2919 CLOSE
tcp 0 0 192.168.0.10:80 192.168.0.2:2517 CLOSE
tcp 0 0 192.168.0.10:80 192.168.0.2:2054 CLOSE
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN

[TiVo [p0] ~]# wget -v http://minnie.tuhs.org -O direct_test.html
--19:12:46-- http://minnie.tuhs.org/
=> `direct_test.html'
Resolving minnie.tuhs.org... done.
Connecting to minnie.tuhs.org[131.244.9.101]:80... failed: Connection timed out.
Retrying.

--19:15:55-- http://minnie.tuhs.org/
(try: 2) => `direct_test.html'
Connecting to minnie.tuhs.org[131.244.9.101]:80...

[TiVo [p1] ~]# wget -v http://localhost:8000 -O proxy_test.html
--19:16:48-- http://localhost:8000/
=> `proxy_test.html'
Resolving localhost... done.
Connecting to localhost[127.0.0.1]:8000... connected.
HTTP request sent, awaiting response...
Read error (Connection timed out) in headers.
Retrying.

--19:31:48-- http://localhost:8000/
(try: 2) => `proxy_test.html'
Connecting to localhost[127.0.0.1]:8000... connected.
HTTP request sent, awaiting response... [TiVo [p2] ~]#

[TiVo [p2] ~]# ls -l *test.html
-rw-r--r-- 1 0 0 0 Feb 28 19:12 direct_test.html
-rw-r--r-- 1 0 0 0 Feb 28 19:16 proxy_test.html

[MattCallow]

It looks like DNS is working ok, but you still can't connect...
You previously tried to connect to http://210.48.107.133:8000/ and it worked. Does that still work?
Can you try
wget -v -t 1 http://www.abc.com.au
and then
http_proxy=http://proxy.netspace.net.au:8080 wget -v -t1 http://www.abc.com.au
and then
http_proxy=http://proxy.netspace.net.au:8080 wget -v -t1 http://minnie.tuhs.org/

[MelissaH]

Here you go:

Thanks, M.

[TiVo [p0] ~]# wget http://210.48.107.133:8000
--21:24:42-- http://210.48.107.133:8000/
=> `index.html.7'
Connecting to 210.48.107.133:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1,858 [text/html]

0% [ ] 1,858 0.00B/s ETA 00:00

Last-modified header invalid -- time-stamp ignored.
21:24:42 (0.00 GB/s) - `index.html.7' saved [1858/1858]

[TiVo [p0] ~]# wget http://210.48.107.133:80
--21:24:52-- http://210.48.107.133/
=> `index.html.8'
Connecting to 210.48.107.133:80...
[TiVo [p1] ~]# wget -v -t 1 http://www.abc.com.au
--21:25:19-- http://www.abc.com.au/
=> `index.html.8'
Resolving www.abc.com.au... failed: Host not found.
[TiVo [p1] ~]# http_proxy=http://proxy.netspace.net.au:8080 wget -v -t1 http://
www.abc.com.au
--21:26:01-- http://www.abc.com.au/
=> `index.html.8'
Resolving proxy.netspace.net.au... failed: Host not found.
[TiVo [p1] ~]# http_proxy=http://proxy.netspace.net.au:8080 wget -v -t1 http://
minnie.tuhs.org/
--21:26:43-- http://minnie.tuhs.org/
=> `index.html.8'
Resolving proxy.netspace.net.au... failed: Host not found.
[TiVo [p1] ~]#

[MattCallow]

Ah, so DNS is not working. you are getting failures when doing host lookups. But, minnie.tuhs.org is probably in your /etc/hosts file (it is in mine).
To summarise:

you can connect to a host on port 8000 if you provide the IP address.
You cannot connect to the same host on port 80.
You cannot resolve hostnames via DNS


Can you try the following (this is the same test as before, but using ip addresses rather that host names):

www.abc.net.au:

wget -v -t 1 http://202.6.74.88
www.abc.net.au via proxy.netspace.net.au

http_proxy=http://210.15.254.253:8080 wget -v -t1 http://202.6.74.88
minnie.tuhs.org via proxy.netspace.net.au

http_proxy=http://210.15.254.253:8080 wget -v -t1 http://131.244.9.101

[MelissaH]

*sigh* i'm really hoping this turns out to be something really simple :-)

thanks,
m.



[TiVo [p0] ~]# wget -v -t 1 http://202.6.74.88
--23:42:10-- http://202.6.74.88/
=> `index.html.8'
Connecting to 202.6.74.88:80... failed: Connection timed out.
Giving up.

[TiVo [p0] ~]# http_proxy=http://210.15.254.253:8080 wget -v -t1 http://202.6.74
.88
--23:45:33-- http://202.6.74.88/
=> `index.html.8'
Connecting to 210.15.254.253:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: unspecified [text/html]

[ <=> ] 22,909 0.00G/s

23:45:34 (0.00 GB/s) - `index.html.8' saved [22909]

[TiVo [p0] ~]# http_proxy=http://210.15.254.253:8080 wget -v -t1 http://131.244.
9.101
--23:45:46-- http://131.244.9.101/
=> `index.html.9'
Connecting to 210.15.254.253:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 7,388 [text/html]

0% [ ] 7,388 0.00B/s ETA 00:00

Last-modified header invalid -- time-stamp ignored.
23:45:47 (0.00 GB/s) - `index.html.9' saved [7388/7388]

[MattCallow]

Now we are making some progress! It looks like your ISP is preventing access to web pages unless you go via their proxy. So, if you configure emuProxyZA to use your ISPs proxy server it *should* work. Now, I'm no expert on emuProxy, but I think the following will configure it to use your ISP proxy:


echo "proxyIP=210.15.254.253" >> /var/hack/etc/emuProxyZA.conf
echo "proxyPort=80" >> /var/hack/etc/emuProxyZA.conf

Now restart your TiVo and try to make a daily call

[MelissaH]

Hey, sorry for the late reply, i've been moving house and have only just got everything set up again...

Not sure if i've done this right, but i changed /var/hack/etc/emuProxyZA.conf as below. It's still not able to make a daily call so feel free to roll eyes if i've done this wrong... Cheers.

# emuProxyZA.conf

# the serverip is specified in /etc/oztivo.conf
# any serverip specified here will be ignored
# modify rc.sysinit.author if you wish to change the emulator address
# serverIP=131.244.9.101

forceUpdate=0
raw=1

# all recognised parameters are listed below:
# taken from http://tivoza.nanfo.com/forum/viewtopic.php?t=180#1268 2/7/06

# debug: 0=No debug, 1=Debug info, 2=Detailed debug info
# serverIP: Guide server DNS or IP address, default: 204.176.49.2 (TiVo Inc)
# serverPort: Guide server port, default: 80
# localPort: emuProxyZA IP address, default: 0.0.0.0
# localIP: emuProxyZA port, default: 8000
# DNSconf: File containing the DNS nameserver, default: '/etc/resolv.conf'
# proxyIP: Proxy server IP or DNS address
# proxyPort: Proxy server port
# proxyUser: Username for proxy authentication
# proxyPassword: Password for proxy authentication
# raw: 1=Raw send, don't "clean" requests to mlog.cgi or HServer.cgi, 2=Raw send without making any unspecified changes to the requests
# onScreen: Display the file being requested on screen via osd_cons
# debugPath: Path to save request & response trace files
# saveRequests: Save request trace files
# saveResponses: Save response trace files
# forceUpdate: 0=No change, 1=Force request to download all new guide slices, 2: Only download latest slices
# timeOffset: Offset returned NTP time by OffsetAmount minutes
# ntpIP: NTP (time server) to use
# guideDays: Maximum guide days you would like to download (your provider needs to support this function for it to work)
# weekDays: The days of the week you wish to download guide data, list each day from 0 to 6 (0 is Sunday). i.e. to download on Tuesdays and Fridays use: -w 25
# locationID: Change your Postal Code
# tcInfo: Fix the submitted TCINFO, so it sends the correct server connection settings not emuProxyZA settings
# urlbase: Download slices direct from server, don't go via emuProxyZA
echo "proxyIP=210.15.254.253"
echo "proxyPort=80"
#proxyIP=210.15.254.253
#proxyPort=80

[MattCallow]

Hey, sorry for the late reply, i've been moving house and have only just got everything set up again...
I thought you'd given up! Hope the move went OK.

The file is not quite right. Looks like you edited the file? My commands were to be run at the command prompt. They would have added 2 lines to the bottom of the file. (I've also just noticed that I gave you the wrong proxy port number it should be 8080 not 80 :o )

Anyway, if you are happy editing the file, I think it should contain


# emuProxyZA.conf

# the serverip is specified in /etc/oztivo.conf
# any serverip specified here will be ignored
# modify rc.sysinit.author if you wish to change the emulator address
# serverIP=131.244.9.101

forceUpdate=0
raw=1

# all recognised parameters are listed below:
# taken from http://tivoza.nanfo.com/forum/viewtopic.php?t=180#1268 2/7/06

# debug: 0=No debug, 1=Debug info, 2=Detailed debug info
# serverIP: Guide server DNS or IP address, default: 204.176.49.2 (TiVo Inc)
# serverPort: Guide server port, default: 80
# localPort: emuProxyZA IP address, default: 0.0.0.0
# localIP: emuProxyZA port, default: 8000
# DNSconf: File containing the DNS nameserver, default: '/etc/resolv.conf'
# proxyIP: Proxy server IP or DNS address
# proxyPort: Proxy server port
# proxyUser: Username for proxy authentication
# proxyPassword: Password for proxy authentication
# raw: 1=Raw send, don't "clean" requests to mlog.cgi or HServer.cgi, 2=Raw send without making any unspecified changes to the requests
# onScreen: Display the file being requested on screen via osd_cons
# debugPath: Path to save request & response trace files
# saveRequests: Save request trace files
# saveResponses: Save response trace files
# forceUpdate: 0=No change, 1=Force request to download all new guide slices, 2: Only download latest slices
# timeOffset: Offset returned NTP time by OffsetAmount minutes
# ntpIP: NTP (time server) to use
# guideDays: Maximum guide days you would like to download (your provider needs to support this function for it to work)
# weekDays: The days of the week you wish to download guide data, list each day from 0 to 6 (0 is Sunday). i.e. to download on Tuesdays and Fridays use: -w 25
# locationID: Change your Postal Code
# tcInfo: Fix the submitted TCINFO, so it sends the correct server connection settings not emuProxyZA settings
# urlbase: Download slices direct from server, don't go via emuProxyZA
proxyIP=210.15.254.253
proxyPort=8080

After editing the file, reboot and try the daily call again. Fingers crossed :)

[MelissaH]

Thanks Matt, yes the move went well - though i also now need to figure out how to get a 3 seater sofa onto the first floor - without using the stairs (at least it didn't get stuck there..) :)

Have made the changes and tried the daily call, it went to 'downloading' for the first time (yay!) and has been there for the last hour... hopefully this is all a good sign...

[petestrash]

Sounds like you are getting somewhere, but an hour is way to long. It's only a few mb's at most that should be downloaded.

Peter.

[MelissaH]

It didn't work unfortunately.. it got stuck on downloading and the tivo was frozen. I turned it off/on and now it's saying the next scheduled call is Thursday, 1st Jan at 00:00.. and most of the log files are saying June 16 as the most recent date. Any suggestions?

Cheers,
Melissa.

[MelissaH]

I tried a few more daily call attempts and this time it went through to either:
Loading Data... 76%, 1 min
or
Loading Data... 98%, 1 min

Getting closer, but just not there yet... any ideas?

Cheers,
Melissa.

[petestrash]

Can you post the most recent attempt part of your tclient.log

Peter.

[MelissaH]

This is all that's in the tclient.log, it seems to have deleted everything else, and it's randomly deleted shows that have been (manually) recorded over the last few weeks..

Melissa.

Jun 16 09:30:48 (none) tcphonehome[182]: Log file rotation complete.
Jun 16 09:30:48 (none) tcphonehome[182]: TClient success
Jun 16 09:30:48 (none) comm[182]: CallStatusReporter: Phase: Prepare_Data, Status Succeeded
Jun 16 09:30:48 (none) comm[182]: CallStatusReporter: sending message "EX|49"
Jun 16 09:30:48 (none) tcphonehome[182]: Sending dialup event, subtype 7, msg Succeeded
Jun 16 09:30:48 (none) tcphonehome[182]: setCallStatus called with: Succeeded state 0
Jun 16 09:30:48 (none) tcphonehome[182]: LastCallAttempt at -995453476
Jun 16 09:30:48 (none) tcphonehome[182]: last attempt in future; set it to now: -995466552
Jun 16 09:30:48 (none) tcphonehome[182]: status is 'Succeeded' == 'Succeeded'
Jun 16 09:30:48 (none) tcphonehome[182]: setting last success time to -995466552
Jun 16 09:30:48 (none) tcphonehome[182]: setting call status to: Succeeded
Jun 16 09:30:48 (none) tcphonehome[182]: setting call in progress to 0 (second successCount)
Jun 16 09:30:48 (none) tcphonehome[182]: setting LastSuccessPgdCall to -995466552
Jun 16 09:30:48 (none) tcphonehome[182]: Setting callActive to 0
Jun 16 09:30:48 (none) comm[182]: CallStatusReporter: sending data changed event 20
Jun 16 09:30:48 (none) tcphonehome[182]: destroying CommGlobals!
Jun 16 09:30:49 (none) tcphonehome[182]: pCommMempool empty
Jun 16 09:30:49 (none) tcphonehome[182]: Setting MCP PhoneHome action: ENABLED

[petestrash]

Well according to that log.

Your last call home was a success. This is why it has been cleared.

Try posting your otclient.log it will show the previous attempts.

Also have you updated your TiVo recently? run oztivo_update -y.

There have been updates to ntpdate which was also causing hanging issues.

Peter.

[MelissaH]

Hi Peter,
Thanks for all your help so far, it is getting closer.... I've attached otclient.log and results of update_oztivo -y. Also, i now get 'upcoming' programs on the tivo, but no actual guide data and the upcoming program doesn't change..

Melissa.

[petestrash]

It seems like a proxy issue still, which is effecting slices.

Are you still testing with the TiVo connected by cable, not wireless ?

if yes, can you please post the content of your /var/hack/etc/emuProxyZA.conf

Peter

[MelissaH]

I've got it set up wireless. But here's /var/hack/etc/emuProxyZA.conf anyway.

# emuProxyZA.conf

# the serverip is specified in /etc/oztivo.conf
# any serverip specified here will be ignored
# modify rc.sysinit.author if you wish to change the emulator address
# serverIP=131.244.9.101

forceUpdate=0
raw=1

# all recognised parameters are listed below:
# taken from http://tivoza.nanfo.com/forum/viewtopic.php?t=180#1268 2/7/06

# debug: 0=No debug, 1=Debug info, 2=Detailed debug info
# serverIP: Guide server DNS or IP address, default: 204.176.49.2 (TiVo Inc)
# serverPort: Guide server port, default: 80
# localPort: emuProxyZA IP address, default: 0.0.0.0
# localIP: emuProxyZA port, default: 8000
# DNSconf: File containing the DNS nameserver, default: '/etc/resolv.conf'
# proxyIP: Proxy server IP or DNS address
# proxyPort: Proxy server port
# proxyUser: Username for proxy authentication
# proxyPassword: Password for proxy authentication
# raw: 1=Raw send, don't "clean" requests to mlog.cgi or HServer.cgi, 2=Raw send without making any unspecified changes to the requests
# onScreen: Display the file being requested on screen via osd_cons
# debugPath: Path to save request & response trace files
# saveRequests: Save request trace files
# saveResponses: Save response trace files
# forceUpdate: 0=No change, 1=Force request to download all new guide slices, 2: Only download latest slices
# timeOffset: Offset returned NTP time by OffsetAmount minutes
# ntpIP: NTP (time server) to use
# guideDays: Maximum guide days you would like to download (your provider needs to support this function for it to work)
# weekDays: The days of the week you wish to download guide data, list each day from 0 to 6 (0 is Sunday). i.e. to download on Tuesdays and Fridays use: -w 25
# locationID: Change your Postal Code
# tcInfo: Fix the submitted TCINFO, so it sends the correct server connection settings not emuProxyZA settings
# urlbase: Download slices direct from server, don't go via emuProxyZA
proxyIP=210.15.254.253
proxyPort=8080

[MattCallow]

It seems strange that there are so many problems. Is anyone else using the same ISP?
(I suggested the proxy settings in the emuProxyZA.conf , which I found on the ISP website)

[petestrash]

now that you have updated the TiVo, Comment out the 2 lines Matt suggested in /var/hack/etc/emuProxyZA.conf

Reboot.

run

/bin/ntpdate -b 132.163.4.103 192.43.244.18 129.6.15.29

to get your clock correct, then force a daily call. Once complete post your tclient.log if unsucessful or otclient.log if successful.

Peter.

[MelissaH]

I removed the 2 lines in /var/hack/etc/emuProxyZA.conf and rebooted It didn't work unfortunately, it went to 'Failed. Service unavailable' The tclient.log results are attached. The time/date is still incorrect also?

Not sure what i was meant to see, but this was the result..
[TiVo [p0] ~]# /bin/ntpdate -b 132.163.4.103 192.43.244.18 129.6.15.29
[TiVo [p0] ~]#

Cheers,
Melissa.

[petestrash]

Ok this proves that the newer emuproxyza still cannot get past your ISP's proxy on it's own.

You shouldn't have seen any response to the ntpdate command, but it should have worked.

Please return the two proxy lines, as least these are getting you closer.

Reboot the TiVo.

Now try ntpdate again as below, this adds -v so you will see what happens:
/bin/ntpdate -b -v 132.163.4.103 192.43.244.18 129.6.15.29

Clear all the current otclient log with:
cat /dev/null > /var/log/otclient.log

Now try a daily call again and post the tclient log again.

Peter.

PS who is your ISP?

[MattCallow]

PS who is your ISP?
A previous post says it's Netspace. That's how I found the proxy info.

I've just been looking at the WiKi and came across this page: http://www.tuhs.org/twiki/bin/view/Network/BypassTransparentProxyServer

Maybe option 3 might work?



Modify /etc/tclient.conf so that instead of pointing to minnie:80 (The line is 127::131.244.9.101:80:::) it reads:

127::202.63.38.134:8000:::

But you are currently using emuproxyZA, so instead change the line

127::127.0.0.1:8000:::
to

127::202.63.38.134:8000:::

[MelissaH]

Hi,
I followed Peter's suggestions and the tclient log is below. I'm with Netspace. The date/time on the tivo is still incorrect though...?

Cheers,
Melissa.

Jun 16 10:31:27 (none) tcphonehome[144]: Log file rotation complete.
Jun 16 10:31:27 (none) tcphonehome[144]: TClient success
Jun 16 10:31:27 (none) comm[144]: CallStatusReporter: Phase: Prepare_Data, Status Succeeded
Jun 16 10:31:27 (none) comm[144]: CallStatusReporter: sending message "EX|49"
Jun 16 10:31:27 (none) tcphonehome[144]: Sending dialup event, subtype 7, msg Succeeded
Jun 16 10:31:27 (none) tcphonehome[144]: setCallStatus called with: Succeeded state 0
Jun 16 10:31:27 (none) tcphonehome[144]: LastCallAttempt at 1173976404
Jun 16 10:31:27 (none) tcphonehome[144]: last attempt in future; set it to now: -995462913
Jun 16 10:31:27 (none) tcphonehome[144]: status is 'Succeeded' == 'Succeeded'
Jun 16 10:31:27 (none) tcphonehome[144]: setting last success time to -995462913
Jun 16 10:31:27 (none) tcphonehome[144]: setting call status to: Succeeded
Jun 16 10:31:27 (none) tcphonehome[144]: setting call in progress to 0 (second successCount)
Jun 16 10:31:27 (none) tcphonehome[144]: setting LastSuccessPgdCall to -995462913
Jun 16 10:31:27 (none) tcphonehome[144]: Setting callActive to 0
Jun 16 10:31:27 (none) comm[144]: CallStatusReporter: sending data changed event 20
Jun 16 10:31:27 (none) tcphonehome[144]: destroying CommGlobals!
Jun 16 10:31:28 (none) tcphonehome[144]: pCommMempool empty
Jun 16 10:31:34 (none) tcphonehome[144]: Setting MCP PhoneHome action: ENABLED

[Darren King]

The date/time on the tivo is still incorrect though...?

Ensure you have port 37 forwarded on your firewall otherwise the TiVo won't be able to set the correct time.

[petestrash]

According to your current tclient log, your last daily call was successful so no info was displayed.

In this case post your otclient log which will show what happened.

You say the time was still not updated. the 2nd ntpdate command I gave you should have shown some messages when it was run.

Peter.

[petestrash]

As a side issue, have you tried contacting netspace and asking them to remove 131.244.9.101 from thier proxies as the proxy is not handling http/1.0 requests properly.

First level customer support won't know what you are talking about, but if they push it up to a technician you should be able to get them to do it.

This would save all these hassles.

Peter.

[TimesOwn]

Ensure you have port 37 forwarded on your firewall otherwise the TiVo won't be able to set the correct time.

Darren are you saying the firewall should map external WAN port 37 to a TiVo's IP port 37 to ensure correct time setting? If so how do multiple TiVo's get mapped? Because the time request comes internally I would not have expected an external port need be open for this. Can you clarify please?

[Darren King]

Ummm... on my Billion 7402VGP I just told it to allow port 37 through to all IP addresses on the network..... Maybe a better choice of words would have been "ensure port 37 is open on the firewall".

[MelissaH]

But you are currently using emuproxyZA, so instead change the line

127::127.0.0.1:8000:::
to

127::202.63.38.134:8000:::

I tried this, but the file is read only? A thousand apologies for my ignorance here... this is clearly not my area of expertise...

The otclient log is attached..

Also, this was the result when I tried to update the date/time (it's still incorrect on the tivo and I can't manually record) :

[TiVo [p0] ~]# /bin/ntpdate -b -v 132.163.4.103 192.43.244.18 129.6.15.29
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
Setting the local time to Sun Mar 18 21:21:42 2007
[TiVo [p0] ~]#

I shall call Netspace this week and see how I go.

Thanks,
Melissa.

[petestrash]

the manual ntpdate command worked for a while (shows 18MAR), according to your otclient log. but the ntpdate which is run during the daily call is killing this as it's not connecting with the server for the correct IP addresses.

To follow matts suggestion we need to change the instructions, you need to do the following.

First we create sysinit.conf

cd /etc
rw
cp dflt_sysinit.conf sysinit.conf

Then disable emuproxyZA, by editing sysinit.conf and changing the line:

emuproxy_enable="YES" # Start one of the emuproxy programs:

to:

emuproxy_enable="NO" # Start one of the emuproxy programs:

and save the file.

Now edit tclient.conf, and change:

127::127.0.0.1:8000:::

to:

#127::127.0.0.1:8000:::
127::202.63.38.134:80:::

Save the file, then ro to make it read only again, then reboot.

Peter

[Darren King]

I tried this, but the file is read only?

You need to put the TiVo into read/write first. Issue the command rw. Then make the changes and afterwards put the TiVo back into read only with the command ro

[MelissaH]

Ok, I made the changes to sysinit.conf and tclient.conf. Am I meant to end up with extra files called sysinit.conf~ and tclient.conf~ that have the old info in them?

The daily call now says 'Failed. No dial-in number chosen.'

The tclient log is attached.

I still have the following in /var/hack/etc/emuProxyZA.conf
proxyIP=210.15.254.253
proxyPort=8080

I called Netspace and they wouldn't do anything (yet), they said the proxy was 'proxy.netspace.au' and the DNS was 210.15.254.253 on port 8080 if that helps at all?

Thanks (for your patience),
Melissa.

[MattCallow]

Ok, I made the changes to sysinit.conf and tclient.conf. Am I meant to end up with extra files called sysinit.conf~ and tclient.conf~ that have the old info in them?
That's just backup files made by the editor. They are fine.


I still have the following in /var/hack/etc/emuProxyZA.conf
proxyIP=210.15.254.253
proxyPort=8080
That should be OK, you have disabled emuProxyZA, so these lines currently have no effect, but it's OK to leave them


I called Netspace and they wouldn't do anything (yet), they said the proxy was 'proxy.netspace.au' and the DNS was 210.15.254.253 on port 8080 if that helps at all?
We already tried this by editing emuProxyZa.conf . It didn't seem to work properly

Can you post the sysinit.conf and tclient.conf please?

[MelissaH]

I've attached the two files..

Thanks again,
Melissa.

[petestrash]

I had a typo, port should be 8000 not 80 in my last instructions to bypass emuproxy.

try this.

cd /etc
rw

Now edit tclient.conf, and change:

#127::127.0.0.1:8000:::
127::202.63.38.134:80:::

to:

#127::127.0.0.1:8000:::
127::202.63.38.134:8000:::

Save the file, then ro to make it read only again, then reboot.

Peter.

[MelissaH]

I made the changes but it is still giving 'Failed. No dial-in number chosen.' as the error message when i try a daily call.

Cheers,
Melissa.

[petestrash]

That is very odd.

Can you please return it to how it was a couple of days ago.

cd /etc
rw

Then enable emuproxyZA, by editing sysinit.conf and changing the line:

emuproxy_enable="NO" # Start one of the emuproxy programs:

Back to:

emuproxy_enable="YES" # Start one of the emuproxy programs:

Save the file, then ro to make it read only again, then reboot, and try a daily call.

If you don't get the failed message, please post your tclient log.

If you do get the failed message, please edit tclient.conf, and change:

#127::127.0.0.1:8000:::
127::202.63.38.134:8000:::

Back to:

127::127.0.0.1:8000:::
#127::202.63.38.134:8000:::

Save the file, then ro to make it read only again, then reboot, and try a daily call.

Would you have the chance to try using someone else's internet service, not netspace just to confirm every thing has loaded on to your TiVo correctly, and we are no barking up the wrong tree?

Peter

PS this is most pain in the A** proxy I have seen. I am very surpised no else is using netspace, or having these issues.

[MelissaH]

I changed sysinit.conf back to:
emuproxy_enable="YES" # Start one of the emuproxy programs:
and the daily call failed.

I then changed tclient.conf back to:
127::127.0.0.1:8000:::
#127::202.63.38.134:8000:::

After reboot, the daily call went through to succeeded and there was guide data on the Tivo, but the date/time was still out. I tried another daily call and it went to 'Loading Data... 99%, 1 min'

I've attached the tclient log from after the successful call (tclient.txt) and the next failed call (tclient 2.txt) and the otclient log.

I will try another ISP early next week - but the successful call is a good sign!!

Cheers,
Melissa

PS, this is doing my head in... but i'm not ready to give up yet!

[MattCallow]

I wonder if your problems are now just caused by the invalid date.
your log file for the 2nd attempt has an earlier date than the 1st attempt. Also in Otclient you have

Jun 16 09:48:25 (none) comm[149]: backChannelLog: @http://127.0.0.1:8000/tivo-service/acceptfile.cgi
Jun 16 09:48:25 (none) comm[149]: backChannelThumb: NONE
Jun 16 09:48:25 (none) comm[149]: timeService: /bin/ntpdate -b 127.0.0.1

but I have

Mar 21 05:29:56 (none) comm[157]: backChannelLog: @http://127.0.0.1:8000/tivo-service/acceptfile.cgi
Mar 21 05:29:56 (none) comm[157]: backChannelThumb: NONE
Mar 21 05:29:56 (none) comm[157]: timeService: /bin/ntpdate -b 132.163.4.103 192.43.244.18 129.6.15.29

So it looks to me like ntpdate is trying to use the wrong timeserver. What I don't know is how to select the correct one(s). I'm sure someone else will know the answer though.

EDIT: Reading the oztivo mailing list archives I see that the list of servers is provided by the emulator when a daily call is made, so now I'm even more confused

[petestrash]

So it looks to me like ntpdate is trying to use the wrong timeserver. What I don't know is how to select the correct one(s). I'm sure someone else will know the answer though

That is right. I mentioned this problem in post #48. The IP's for ntpdate are fetched from minnie during the daily call and without receiving these, it uses the loopback address.

This is now the reason why daily calls are not completed 100%.

Problem is, I don't currently have a solution for this.

Peter.

[MattCallow]

Ah, more reading reveals this:


oztivo ntpdate version 1.21 will now look for the file /etc/ntpdate_local_ip
and read the first line of text from this file and uses it as the IP
address of the first time server to consult.

Thus, if you want to set up your own time server which will also work
with daily calls, then create the file /etc/ntpdate_local_ip and put
the IP address into that file.

So, maybe forcing a valid time server here will fix it? My suggestion is:
- edit /etc/ntpdate_local_ip and add 132.163.4.103 as a timeserver.
- test the ntpdate command
- retry the daily call
To do this, enter the following:


cat /etc/ntpdate_local_ip
rw
echo "132.163.4.103" > /etc/ntpdate_local_ip
ro
ntpdate -v -b 127.0.0.1
date

Try a daily call, then post the output of all commands.

[petestrash]

Good catch, I forgot about the new feature that Warren wrote into the latest ntpdate.

Once the IP is entered into /etc/ntpdate_local_ip, you don't need any IP when running the command. So ntpdate -v -b is ok, though either will work.

Peter.

[MattCallow]

Once the IP is entered into /etc/ntpdate_local_ip, you don't need any IP when running the command. So ntpdate -v -b is ok, though either will work.
.
I realise that you don't need to specify an ip address on the command line, the reason for doing so is to simulate what the daily call will do. If it works on the command line then i'll have more confidence that it'll work in the daily call.

[MelissaH]

You guys rock!! It went to 'succeeded' and the date/time is correct and I now have guide data for channels 2,9 and SBS! Don't know what has happened to 7 and 10 - hopefully they are just a bit slow..?

Either way - fantastic work, thank you so much for your help!!!

Melissa.


[TiVo [p0] ~]# cat /etc/ntpdate_local_ip
cat: /etc/ntpdate_local_ip: No such file or directory
[TiVo [p0] ~]# rw
File system is now READ/WRITE.
[TiVo [p0] ~]# echo "132.163.4.103" > /etc/ntpdate_local_ip
[TiVo [p0] ~]# ro
File system is now READ ONLY.
[TiVo [p0] ~]# ntpdate -v -b 127.0.0.1
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
Setting the local time to Thu Mar 22 07:19:45 2007
[TiVo [p0] ~]#

[petestrash]

I realise that you don't need to specify an ip address on the command line, the reason for doing so is to simulate what the daily call will do. If it works on the command line then i'll have more confidence that it'll work in the daily call.

Thats cool, just I know it will work both ways.

Good news Melissa.

What suburb are you in, so I can add Netspace to my PITA ISP's list.

Peter.

[MelissaH]

I'm in Richmond, Melbourne.

Any idea why i wouldn't have the guide data for channel 7 and 10? Also, am i going to have all sorts of trouble each time there is a software update?!

Cheers,
Melissa.

[petestrash]

When was you last daily call?

If before 5pm ESDT today, force one now and post your otclient log once successful.

Yes you will have problems with update, but we can overcome them.

cd /etc
cat update_exclude

This will list the contents of that file, if it exists. Post the details here.

If it doesn't exist, the use your editor of choice to make a new file called update_exclude

remember to use rw to make the system read/write first.

Paste the following into it.

/hack/etc/emuProxyZA.conf
/etc/ntpdate_local_ip

save the file, and use ro to make system read only.

Peter.

[MelissaH]

I made another daily call and the guide data is all there now - yay! I also made the suggested changes to update_exclude.

Thank you everyone for your help, I love my tivo again!!

Cheers,
Melissa.

[petestrash]

Good news, happy to help.

Peter.

[MattCallow]

Excellent. Glad it's all working now.

[petestrash]

Melissa,

Are you on ADSL or ADSL2

Peter.