Printable View
The most common reason is that the command does not have "eXecute permission". You can check this by "ls -l /bin/ntpdate" where you will find that the first column (which shows the permissions) will look something like "-rw-rw-r--". The easiest way to fix this is to do a "chmod 755 /bin/ntpdate", after which the permissions should look like "-rwxr-xr-x".Quote:
Originally Posted by dyrplq
Great. That was it. Now what does it mean when I get no response at all from running the ntpdate command?
I would have expected a usage message... something similar to:Quote:
Originally Posted by dyrplq
usage: /bin/ntpdate [-bBdqsv] [-a key#] [-e delay] [-k file] [-p samples] [-o version#] [-r rate] [-t timeo] server ...
Are you able to provide the output of "ls -l /bin/ntpdate"? I am guessing it is a link to a differnet file (most likely a script). I unfortunately do not know very much about the OzTivo system installations, but I would have expected some sort of output to be produced.
Thomson is right entering /bin/ntpdate should produce:
ntpdate [-B] [-b] [d] [-q] [-v] server [server ...]
Using the correct syntax /bin/ntpdate -b 192.43.244.18 129.6.15.29 132.163.4.103 should produce:
gmtime gives 106/3/29 10:14:27 [6]
sending to clock 06/04/29 10:14:27 [6]
Peter.
I seem to be having this fault also (constantly getting the warped clock issue). I have followed through these posts and have got to this final message which states I should see a result but unfortunately I don't (although there is no error either like earlier when I had the "permission" error). What next?
Thanks in advance.
Muzza.
Likewise Muzza, I also dont get a response from this command, so I run the touch timestamp command via Cron each night. I know that this is a 'workaround' and that I shouldn't have to do this at all, but it works for me.
Cheers, Phil.
When you say running the command does not produce any result, how long did you wait?
depending on your TiVo's load it could take around a minute or so to produce a report.
So when you say it does not produce the result, does it come straight back with a prompt or only a cursor square? If cursor square, this is correct and when the fetch is completed the results should show.
Can you both please try the following and post the results.
Peter.Code:[TiVo [p0] ~]#
[TiVo [p0] ~]# cd /bin
[TiVo [p0] /bin]#
[TiVo [p0] /bin]# ls -l ntpdate
-rwxr-xr-x 1 0 0 59473 Apr 23 2005 ntpdate
[TiVo [p0] /bin]#
[TiVo [p0] /bin]# /bin/ntpdate -b 192.43.244.18 129.6.15.29 132.163.4.103
gmtime gives 106/4/15 09:37:09 [1]
sending to clock 06/05/15 09:37:09 [1]
[TiVo [p0] /bin]#
This is the result I get......
[TiVo [p0] ~]# cd /bin
[TiVo [p0] /bin]#
[TiVo [p0] /bin]# ls -l ntpdate
-rwxr-xr-x 1 0 0 59473 May 15 08:51 ntpdate
[TiVo [p0] /bin]#
[TiVo [p0] /bin]# /bin/ntpdate -b 192.43.244.18 129.6.15.29 132.163.4.103
[TiVo [p0] /bin]#
[TiVo [p0] /bin]#
I noticed that it was actually 8:09am May 16 when I did this but if you see above it says a different time and date (maybe that is normal though??).
I have been carrying out a: "touch /var/timestamp" & "/hack/bin/force_index.tcl" continusously over the last few days but my TiVo just won't sort itself out now. This always used to fix the fault for several weeks but now I have been unable to get a successful guide data update for about a week (and of course season passes etc don't work). Last night (after a TiVo restart), I managed to get some data back but it again failed at about 10% or so. Ususally over the last week, I get "failed while preparing data" at about 1%. I have still got no data on several channels.
Getting frustrated now......any ideas??? :(
Ok, it sounds like your tivo is having issues calling out to the internet. This is probably why you also don't get a result from the ntpdate command.
try following the steps @ Configuration_and_Diagnostics to see why your TiVo is not responding.
Peter.
As far as connectivity goes - a test call always works ok and it says it connects ok and has finished downloading ok when you do a normal daily call from TiVo-Web but it just fails when it prepares the data. This always used to come right once a index fix had been run but doesn't seem to be this time round.
I will however look through the link you supplied when I get home just in case.
Cheers.