Printable View
I am finding when the Internet has been disconnected (ISP issues) I do a manual data download via version 2.0.0's Phone page that it gets stuck in a loop on the Last Attempt Status: "SettingUp", however it does seem to suceed, as noted in the info page and on refreshing the Phone page it shows suceeded. 1.3.1 (2 off) does not seem to do this.
Try the latest distribution (070304) v2.0.0 and see if it resolves the problem.Quote:
Originally Posted by TimesOwn
Cool thanks, will let you know Thomson, might take a week or two before I'll know.
Seems to have stopped the perpetual cycle and reintroduced the "Failed getting account status" Could that be helpful? Test call was fine again. Cleared the client log, (saved if any use)
That didn't fix the Failed getting account status either.
Is it just the one Thomson unit playing up or all of them.
Peter.
Its now been 2 out of 3.
I have since loaded up TWP 070305 and it ran fine first up with no test call necessary!
Test calls don't actually test much and are fairly useless.
Are the daily calls still failing though ?
Peter.
Daily calls up again! I wonder if the server has limited traffic numbers in some way such as a maximium allowed number of connections allowed or may be down some times? Next time it happens I'll not use a test call then, it seemed to trigger the proper call going through, but perhaps this was just a function of it subsequently "getting through"
Ok, next time daily call fails post the tclient.log in a new thread.
Peter.
Re Thomson 04-03-2007 01:46 PM this issue does not seem to be resolved yet with 2.0.0 070305. (How do I insert the quote?!)
Re new thread will do as the problem persists. I'll Call it Failed Getting Account Status - Thomson
As suggested new thread started for continuing problems of "Failed Getting Account Status" This has happened frequently on 1.3.1 but seemed to be manually overcome by clearing the tClient log. On 2.0.0 this does not remedy the problem. The log is attached.
It's still failing at the same location as before.
03/12:08:44:59: /tvbin/TClient: Executing HTTP POST: /tvbin/http_post /var/tmp/syslog.gz http://210.48.107.133:8000/tivo-service/acceptfile.cgi OFF ON
03/12:08:48:01: /tvbin/TClient: http POST command failed: timeout waiting for data
03/12:08:48:01: /tvbin/TClient: sending AreaCodes changed event
03/12:08:48:01: /tvbin/TClient: backHaulDone is 0
03/12:08:48:02: /tvbin/TClient: registerNewSoftware: getting SwSystemName
03/12:08:48:02: /tvbin/TClient: Software system 2.5.5-01-1-023 is present and active
03/12:08:48:02: /tvbin/TClient: updateStatus: Failed ST| 34 26
I can't tell why you are not getting confirmation from the emulator. Maybe someone can check the emulator logs to see if there are any clues.
Peter.
The server logs were kindly sent to me, here they are, does this help at all?
Server logs didn't help :(
Stupid thing is acceptfile.cgi is only used to upload your logs and thumbs ratings to the emulator, which we don't use here.
Is it working intermittantly or not at all.
Peter.
It seems that there could be a communications issue between you and the server? Would be interesting to know if others are having similar issues.
Might be worth seeing if the following works from the command line?
Code:/tvbin/http_post /var/tmp/syslog.gz http://210.48.107.133:8000/tivo-service/acceptfile.cgi
As noted in the other thread on this issue, I had the same problem around about December running 2.5.5, but after it magically came right have not had it again since (I say that with my fingers crossed for good luck that it doesnt happen again).Quote:
Originally Posted by thomson
I have occassionally had it stuck on "setting clock" (ie the for 24 hours), but a reboot seemed to let the next attempt connect ok.
I get:
[TiVo [p1] ~]# /tvbin/http_post /var/tmp/syslog.gz http://210.48.107.133:8000/tivo-service/acceptfile.cgi
usage
Usage: /tvbin/http_post <filename> <URL> <ON|OFF> <ON|OFF> [<ON/OFF>]
[TiVo [p1] ~]#
Looks like I need to set the switches also - but to what?
OK, I used the swithces as the TiVo was using as identified by Pete above:
[TiVo [p1] ~]# /tvbin/http_post /var/tmp/syslog.gz http://210.48.107.133:8000/tivo-service/acceptfile.cgi OFF ON
Thu Mar 15 12:41:57 2007: /tvbin/http_post invoked
connecting to 210.48.107.133:8000
select-ing for header
Seems to hang here....
[TiVo [p1] ~]# /tvbin/http_post /var/tmp/syslog.gz http://210.48.107.133:8000/tivo-service/acceptfile.cgi OFF ON
Thu Mar 15 12:43:20 2007: /tvbin/http_post invoked
connecting to 210.48.107.133:8000
select-ing for header
timeout waiting for data
timeout waiting for data
[TiVo [p1] ~]#
This TiVo with 2.0.0 is running out of data. Are there file(s) I can copy off the other TiVo's, which are generally getting their data (1.3.1's), to keep this other TiVo on track for recording?
You need to manually load the slices from the emulator.
I don't believe you can get them from a TiVo.
Peter.
Might pay to check for potential issues with firewall rules and even the size of the /var/tmp/syslog.gz as it could be that this is very large or corrupted?Quote:
Originally Posted by TimesOwn
It is curious that the 1.3.1's do not have such a problem as they can be updated, all be it sometimes manually, this is not the case with the 2.0.0, which does seem to point to some difference in the 2.0.0 code?
/var/tmp/syslog.gz is 0.13MB and is dated at the last time an update was attempted - and suceeded spontaneously this morning!!!
The firewall is pfSense, which is an industrial class firewall. See http://pfsense.org/ No ports are specifically opened for the TiVo's. Any suggestions on tests to confirm the firewall is not interfering? I am not sure if one can map the same external port to multiple LAN IP's, and this is in my experience unusual of firewalls. Darren, what is the model of your Bullion, I am interested to check this out.
On checking I noted that my firewall's ARP table only reported one of the 3 static TiVo's (which do have different Ip and MAC addresses) however the hostnames were not reported either. I edited two of the Host names in /etc/dhclient.conf to make these unique, now the 3 statics appear in the ARP table, although the host names remain unreferenced. Makes me wonder if this might have been a factor in the problems? Did I do this host name change in the right place?
Not sure about UK v2.5.5, but the current OzTiVo release 1.6.2 sets it via oztivo.conf.
dhclient.conf was previoulsy used.
Peter.
Interesting. My oztivo.conf says:
# OzTiVo menu configuration settings file
# Please do not edit this file
# Put the TiVo disk back in your PC to reconfigure
nic=Cachecard
ip=192.168.x.x
mac=A0:0B:AD:A0:0A:1D
hostname=
modem=0
pppondss=0
netmask=255.255.255.0
gateway=192.168.x.x
ssid=
wep=
wepkey=
I'd be happeir to put it in here and try it if it didn't say the first 3 commented lines, which do not seem to make sense, given the presumed purpose of this file, typically one would control the settings here and maybe reboot? Presumably if one keeps the details in /etc/rc.d/rc.net consistent it should be ok to edit here and there simultaneously? Are there other places to coordinate also that the PC installer does, noting it does not offer the option of hostname, at least that I recall?
Since hostname= is blank your version of software does not take it from here.
The reason we don't want people manually changing the file is that it is read by other programs, and setup by the installer.
Peter.