I've attached the two files..
Thanks again,
Melissa.
That's just backup files made by the editor. They are fine.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 should be OK, you have disabled emuProxyZA, so these lines currently have no effect, but it's OK to leave themI still have the following in /var/hack/etc/emuProxyZA.conf
proxyIP=210.15.254.253
proxyPort=8080
We already tried this by editing emuProxyZa.conf . It didn't seem to work properlyI 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?
Can you post the sysinit.conf and tclient.conf please?
I've attached the two files..
Thanks again,
Melissa.
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.
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.
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.
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!
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
but I haveCode: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
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.Code: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
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
Last edited by MattCallow; 21-03-2007 at 10:25 PM.
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.
Ah, more reading reveals this:
So, maybe forcing a valid time server here will fix it? My suggestion is: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.
- 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:
Try a daily call, then post the output of all commands.Code:cat /etc/ntpdate_local_ip rw echo "132.163.4.103" > /etc/ntpdate_local_ip ro ntpdate -v -b 127.0.0.1 date
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.
Bookmarks