Time setting in daily call making date wrong

Ok attached are the logs.

Quote:

---

Originally Posted by gazman88

Ok attached are the logs.

---

Hi 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:

Code:

---

rm /etc/ntpdate_local_ip

---

Once done you can perform another call in after which could you please zip up the logs and post them here again.

To simplify the zipping up of the logs run the following from your TiVo:

Code:

---

tar -czvf /tmp/proxyLogs.tgz /var/log/emu*.log /var/log/ep*.log /var/log/*tclient

---

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:

---

rm /var/log/emu*.log
rm /var/log/ep*.log
rm /var/log/*tclient

---

As requested here is the latest log files.

Quote:

---

Originally Posted by gazman88

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:

Code:

---

ɼ o

---

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:

• 132.163.4.102
• 192.43.244.18
• 129.6.15.29

e.g.

Quote:

---

ntpIP=132.163.4.102

---

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.

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?

Quote:

---

Originally Posted by petestrash

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.

---

Correct, the reason the 'ntpdate_local_ip' file was removed in post 12 was to enable ntpdate to route it's request through emuProxyZA.

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