Printable View
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.
TPG seems to be blocking your time calls.
Try the following in putty.
rw
echo "132.163.4.103" > /etc/ntpdate_local_ip
ro
ntpdate -v -b
Then paste the results here.
Peter.
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
Quote:
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.
Ok attached are the logs.
Hi gazman88Quote:
Originally Posted by gazman88
Thanks for the logs, only problem is ntpdate is currently bypassing emuProxyZA. To fix this, could you delete the 'ntpdate_local_ip' file as follows:
Once done you can perform another call in after which could you please zip up the logs and post them here again.Code:rm /etc/ntpdate_local_ip
To simplify the zipping up of the logs run the following from your TiVo:
This will leave you with just the one file 'proxyLogs.tgz' in the TiVo's '/tmp' directory which you can copy off the TiVo and post here. To prevent the logs from containing too much unnecessary data it would be best to clear the current logs before performing each new call-in, this can be done as follows:Code:tar -czvf /tmp/proxyLogs.tgz /var/log/emu*.log /var/log/ep*.log /var/log/*tclient
Code:rm /var/log/emu*.log
rm /var/log/ep*.log
rm /var/log/*tclient
As requested here is the latest log files.
Either your ISP is blocking the request to the time server or the time server is failing to respond, the later seems to be happening quite frequently as of late. The 'ep7Response.log' lists the time server request as having a "Bad gateway". What happens when you open up "http://132.163.4.103:37" in a web browser? The result should be similar to the following:Quote:
Originally Posted by gazman88
Try testing a couple of other time servers, to do so edit '/hack/etc/emuProxyZA.conf' file and set the "ntpIP" parameter (look for the one without the # in front of it) to one of the following addresses:Code:ɼ o
- 132.163.4.102
- 192.43.244.18
- 129.6.15.29
e.g.
Once set, you'll need to kill and restart emuProxyZA or reboot your TiVo for the changes to take effect. You can then proceed to perform a call in, generating the logs as before.Quote:
ntpIP=132.163.4.102
What is the difference between ntpdate -v -b and /bin/ntpdate -b -v 132.163.4.103 192.43.244.18 129.6.15.29?
This is what I get when I run the two.
[TiVo [p0] /hack/etc]# [TiVo [p0] /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
[TiVo [p0] /hack/etc]#
[TiVo [p0] /hack/etc]# /bin/ntpdate -b -v 132.163.4.103 192.43.244.18 129.6.15.29
Our postcode is 02000. Found matching timezone Australia/Sydney
Offset 36000 for timezone EST, daylight saving is 0
Connecting to time server 132.163.4.103
Setting the local time to Tue Apr 3 17:23:56 2007
gmtime gives 107/3/3 17:23:56 [2]
sending to clock 07/04/03 17:23:56 [2]
[TiVo [p0] /hack/etc]#
I don't understand why one works and sets the time correct whilst the other one doesn't.
When you entered "echo "132.163.4.103" > /etc/ntpdate_local_ip" back in post #4 this set the default NTP address as 132.163.4.103. So when running ntpdate you shouldn't need any of the IP addresses.
This was then removed in post #12, so using ntpdate on it's own will no longer work.
So is the time setting in the Daily call still not working?
Peter.
The time setting is not working during the Daily call. I guess there seems to be a problem with the clock setting during the daily call only. I can set the time using the ntpdate so I don't have a problem with accessing the time servers.
When I run http://132.163.4.103:37 I do get some funny characters returned to my web browser.
A workaround for me would be to disable the time setting part of the daily call. Can I do this?
Correct, the reason the 'ntpdate_local_ip' file was removed in post 12 was to enable ntpdate to route it's request through emuProxyZA.Quote:
Originally Posted by petestrash
If running ntpdate lead to a successful result then there would be no need to route the request through emuProxyZA. Since your ntpdate requests are failing, running it through emuProxyZA allows us to see the server response such as the "Bad Gateway" error listed above. The other reason you may need to route ntpdate request through emuProxyZA is if you're making use of a proxy server to retrieve the guide updates, ntpdate doesn't directly support proxies and it thus need to be route it's request through emuProxyZA in order to do so.
Can I suggest replacing
proxyIP=proxy2.tpgi.com.au
proxyPort=3128
In /var/hack/etc/emuProxyZA.conf with
proxyIP=proxy.tpg.com.au
proxyPort=80
See if that helps.
Peter
hmm. looking at the output of the ntpdate command, it looks to me like you dont have the latest version. so it probably wont read ntpdate_local_ip. afaik, you need version 1.21, which will report its version when run with -v
Here are the latest logs with following settings in emuProxyZA.conf
proxyIP=proxy.tpg.com.au
proxyPort=80
ntpIP=129.6.15.29
i have the exact same problem as gazman (again). once i got my daily call working using emuproxyZA, the daily call was throwing the time forward by 2 hours. after trying to fix it, i ended up getting some very date/time settings (ranging from 1948 through to 2028). now even with my Tivo set to the correct time, the daily call status hasn't seem to have updated, and it thinks it last did one on Jan 1 of 2028. even if i perform a successful daily call now, it won't change this setting. what that leaves me is with a Tivo that thinks it hasnt done a daily cal in more than 30 days, but it has the correct guide data. if i press the live tv/guide button, it gives me the no daily call error message. but when i change the channel, the banner of each channel is correct. and i can view the information via the channel grid in tivoweb.
is there any way to reset the daily call status, or delete all guide data and information about last successful daily call? i suspect this is causing the most problems.
i may have had a small win. i left my tivo overnight after getting utterly nowhere, other than frustrated. this morning, i played some more with emuProxy - most important of which i think is making sure the timeoffset was not commented out, and was set to 0. once i did this, i ran a ntpdate -v -b with those three time servers included, and it worked. i then tried a daily call, and not only did it work, but it reset the information on the Phone page of Tivoweb, which had been showing the wrong thing. so far, it's been about 12 hours, and everything seems to be working.
well, it lasted 4? days, but i came home tonight to the dreaded "Tivo has not updated for 30 days" message when i checked the guide, and sure enough, puttied in to find the date was 1932. i've been able to reset the date, perform a daily call, and eventually get everything back working again, but i really have no guarantee it will continue to work.
also, Tivo had cut a swathe through my recorded shows, and decided that anything that was recorded via a Season Pass in the last two weeks would have to get deleted. it is also now has nothing in the ToDo list.
I'm going to call TPG tomorrow when I get to work, and follow up with them to see if they can do something about whatever change they made that started all this for me. in the meantime, my current question is, should i just bite the bullet and perform an upgrade to the latest Tivo image? will this help at all? after that, my next step is to start again from scratch. if i can avoid either of these options, i'd be a happy man.
does anyone have any advice (other than change ISP? if i can't get much help out of TPG, i may investigate changing)?
I'm not sure if updating to the latest image is going to help since I am using the latest.
How long has you Tivo been working for you got this time date issue? I only recently got my Tivo about a month back and I have only ever had it running fully for a handful of days at a time. The only feature I can use at the moment is the pause and rewind live TV.
well - given that, i won't go updating!
mine's been working fine since April of last year, and fine with TPG at this address since August. easter thursday it started giving me the service unavailable error message, and has been playing up since. ive had some limited success, but im not confident that it will behave itself permanently again.