Daily call not working

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