Please tell us whether you are from NZ or Australia as the time servers used are different.
Force a daily call then post your otclient log here if successful. If not successful post your tclient log.
Peter
Hi all,
My Tivo after a few days of running perfectly all of a sudden is set to the wrong date and time (dates have been set to Jun 16 2000 and most recently Jun 16 1938 with the time completely wrong). It appears the setting clock feature is changing the date.
I ran /bin/ntpdate -b -v 132.163.4.103 192.43.244.18 129.6.15.29 and I got the right time but as soon I run the daily call (from Tivoweb) the time is wrong again.
Please help!
Gazman
Please tell us whether you are from NZ or Australia as the time servers used are different.
Force a daily call then post your otclient log here if successful. If not successful post your tclient log.
Peter
I'm in Australia. Here is the otclient log. According to the status the call successed 10:03am 16-Jun-00.
Here are the results
[TiVo [p0] ~]# ntpdate -v -b
Failed 4 times to get_postalcode
[TiVo [p0] ~]#
[TiVo [p0] ~]#
I think the get_postalcode error a red herring.
Try the following:
[TiVo [p0] ~]# get_postalcode
You should get the response 02000 (for NSW)
If you don't, please do the following
[TiVo [p0] ~]# cat /etc/postcodezones
And show what results you get.
If you did get 02000 then it's your ISP's proxy still causing issues. Try the following:
Enter the following commands (in red) at the putty prompt:
[TiVo [p0] ~0]# echo " " >> /var/hack/etc/emuProxyZA.conf
[TiVo [p0] ~0]# echo "proxyIP=proxy2.tpgi.com.au" >> /var/hack/etc/emuProxyZA.conf
[TiVo [p0] ~0]# echo "proxyPort=3128" >> /var/hack/etc/emuProxyZA.conf
[TiVo [p0] ~0]# reboot
Once your tivo is rebooting, you can close putty.
Once restarted force a daily call using TiVoWeb or TiVoWebPlus.
Peter.
I have tried the get_postcode and I got this
[TiVo [p0] ~]# get_postalcode
retrying after errTmBackgroundHoldoff ...
retrying after errTmBackgroundHoldoff ...
retrying after errTmBackgroundHoldoff ...
retrying after errTmBackgroundHoldoff ...
02000
[TiVo [p0] ~]#
So I could get the postcode. So I tried adding the proxy settings to emuProxyZA.conf file and ran the Daily call and the time is still wrong. The status of the daily call is successful.
I reran the ntpdate -v -b and got the following
[TiVo [p0] ~]# ntpdate -v -b
Our postcode is 02000. Found matching timezone Australia/Sydney
Offset 36000 for timezone EST, daylight saving is 0
Failed to connect to any of the time servers
[TiVo [p0] ~]#
Attached is the latest otclient log
Enter the following commands (in red) at the putty prompt:
[TiVo [p0] ~0]# echo "ntpIP=132.163.4.103" >> /var/hack/etc/emuProxyZA.conf
[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.
I get the same error
[TiVo [p0] /var/hack/etc]# ntpdate -v -b
Our postcode is 02000. Found matching timezone Australia/Sydney
Offset 36000 for timezone EST, daylight saving is 0
Failed to connect to any of the time servers
My emuProxyZA.conf contains the following
proxyIP=proxy2.tpgi.com.au
proxyPort=3128
ntpIP=132.163.4.103
Can you follow tivoZA's instructions
If you could enable the debug log and trace files in emuProxyZA, this should enable us to determine where the problem lies.
First thing that needs to be done is to kill the running instance of emuProxyZA, this is done as follows:
You can now start emuProxyZA with the debug and trace files enabled as follows:Code:ps ax (look for the emuProxyZA pid in the list returned) kill pid (replace pid with the emuProxyZA pid from above e.g. kill 154)
Once done, you can initiate a daily call and wait until if fails.Code:/hack/bin/emuProxyZA -ds /var/log/ -dc /var/log/ -d2 > /var/log/emuProxyZA.log 2>&1 &
Your TiVo's '/var/log/' directory should now contain a file named 'emuProxyZA.log', this is the debug log. There should also be a number of files named 'epXRequest.log' and 'epXResponse.log' (X being a number), these are the trace files of all the requests made by your TiVo and the responses received from the server. If you could zip up both the debug log as well as all the trace files and post them here, we may be able to determine where things are failing.
Bookmarks