Thomson port 8000 - fails getting account status

[timcapper]

Hi,

I'm running a Thomson Scenium with NZ build connecting to the emulator on port 8000. Since the switchover to the new system yesterday, my Tivo fails on the daily call with the message "failed getting account status". It worked fine prior to the changeover, apart from the FTA channels being on the wrong frequency (I run a cron job to correct).

Any help would be greatly appreciated, you guys do a great job!

Tim

[timcapper]

whatever you did - thanks guys, I just forced a daily call again and this time it worked.

cheers!

[DJC]

Nothing was done, that any of us are aware of :confused: Might pay to keep an eye on your unit for a while.

We tested a UK image on the new system (of course) it worked ok. And nothing about the emulator itself has changed, just the way the community guide slices are constructed, further the changes went live this morning not yesterday.

[timcapper]

hmm, I had changed nothing my end either. Thanks anyway!

[catdog]

I got this error a few weeks ago (UK 2.5.5, port 8000) and tried everything to get it to connect... running emuproxyza and checking the logs for errors etc. In the end it just worked with everything configured as it was previously - the only thing I did differently was to force a test call then force a daily call!

[TimesOwn]

You might like to consider running up the new zip code, as per http://forums.oztivo.net/showthread.php?t=912 , as it may well fix the channel issue for you, although it seems you have anyway? The new ones 0212x are particularly for the Thomsons.

[finethen]

Yup thats the ticket just run guided setup and apply the new post codes as per link above, works great. So good I might reimage and upgrade the drive size. Thanks to the TiVo tinkerers once again!

[TimesOwn]

I have been getting this for the last 3-4 days now. Today I tried a test call, worked fine, but then the manual "Make Daily Call Now" also got the message "Failed getting Test Account Status". System Information says the account status is "3: Account in good standing" This is the last NZ Thomson beta image running TWP 070111. I have 3 all the same, curiously only 1 is doing this. Of course it is the main one though!

[jaidev]

Are you sure it says "Test Account Status? I've never seen Test Account Status. Usually it's "Failed getting/retrieving Account Status"
Does it say the same after a doing a Clear all guide data, and redoing a daily call? Backup season passes first.

[TimesOwn]

Hey that's odd, I typed "Failed getting account status" Not sure how that happened! Possibly a cut n paste format error? Will try and advise.

[TimesOwn]

OK Did that, TiVo rebooted, threatened to take an hour to delete all the stuff, did a manual data update, same message - "Failed getting account status"

[TimesOwn]

OK Did that, TIVo rebooted, Same error occurs when downloading data.

[TimesOwn]

I did a test call and then tried downloading the data again, this time successful. Hmm! Will continue watching it.

[petestrash]

Might want to attach a copy of tclient log from the next failed attempt to help diagnose the problem.

Peter.

[TimesOwn]

Good old Firefox, was looking at it, (as you had mentioned it in your post today!) was still in a TAB so here it is! I see it is now empty.

[petestrash]

I'm not an expert on V2.5.5 software as I only use v3.0, but it does appear the following timeout is the cause of the problems:

01/28:08:24:10: /tvbin/TClient: Executing HTTP POST: /tvbin/http_post /var/tmp/syslog.gz http://210.48.107.133:8000/tivo-service/acceptfile.cgi OFF ON
01/28:08:27:10: /tvbin/TClient: http POST command failed: timeout waiting for data

Peter.

[TimesOwn]

Hmm same TiVo has done it again. Tclient log is now at www.cheqsoft.com/TiVo/TiVoTClientLog2007-2-4.txt (as it is too long to attach!)

[petestrash]

The timeout has occured at the same location, i'm not familiar with the UK software. http_post is not used in V3.0 for our daily calls. It looks like orac is not responding to your request.

Peter.

PS you can attach Zip files here as well as text.

[petestrash]

Have you got an Otclient log which shows your last successful call ?

Peter.

[TimesOwn]

I have it from another machine here Peter, which might help, I post both. (Thank you for your continuing assistance!)

[jaidev]

This is the only reference I have found to a similar issue as yours.
You could try the 3rd post suggestions there and see if that works. We will take it from there..

http://archive.tivocommunity.com/tivo-vb/showthread.php?s=&threadid=74036

[TimesOwn]

Sounded a similar situation in that I have three tivos here, only one misbehaving.

OK have done:

cd /var/log
touch xxxx
cp xxxx tivoLog.prv
cp xxxx tivoLog.prv.gz

tivoLog.prv.gz.bfg does not exist so could not do. Might be a proprietary encryted file bypassed in our units?

Make Daily Call failed again with same basic message of Failed...
Make Test Call Now worked fine
Make Daily Call Now seemed to work, it spent ages setting the clock as it does......and it still is, seems like it is downloading the whole lot of data again. Bed time! I hope that helps?

[TimesOwn]

8 hours later it is still setting the clock! ok Reboot.

Using Remote Test EPG OK
Using Remote EPG Download EPG OK (Wahoo!)

I think there could be two bugs here.
1) The main problem whatever that is!
2) Possible confounding time server not responding. This was considered around the new year, however I can't find the references. I didn't hurry to apply the fix as I was not convinced the NZ architecture was fully compatible and I did not get around to test it - not being an easy thing to test! Anyone got the thread link?

Incidentally it seems the xxxx exercise is merely one in clearing the logs. I now see one can also do this using TWP from the log page! (Quicker and easier!)

[petestrash]

can you look through the tclient or otclient log to find the lines which mention ntpdate as this is where the clock is being set and post here.

Peter.

[TimesOwn]

tclient is now empty.
from current otclient:
02/06:10:47:15: /tvbin/TClient: timeService: /bin/ntpdate -b 210.48.107.133
02/06:10:47:15: /tvbin/TClient: sequenceCookie: 12345678
02/06:10:47:15: /tvbin/TClient: inventoryFile:
02/06:10:47:15: /tvbin/TClient: noPrivBackhaul: 1
02/06:10:47:15: /tvbin/TClient: serviceState: 3
02/06:10:47:15: /tvbin/TClient: stateExpiration: 0
02/06:10:47:15: /tvbin/TClient: swSystemName: 2.5.5-01-1-023
02/06:10:47:15: /tvbin/TClient: infoCode:
02/06:10:47:15: /tvbin/TClient: tcdMessage:
02/06:10:47:15: /tvbin/TClient: globalMessages:
02/06:10:47:15: /tvbin/TClient: keyServer:
02/06:10:47:15: /tvbin/TClient: forceBackhaul: 0
02/06:10:47:15: /tvbin/TClient: publicLogFilter:
02/06:10:47:15: /tvbin/TClient: dbLoadOrder: PG.*
02/06:10:47:15: /tvbin/TClient: regenToken: 0
02/06:10:47:15: /tvbin/TClient: backhaulDataOn: 0
02/06:10:47:15: /tvbin/TClient: personalDataOn: 0
02/06:10:47:15: /tvbin/TClient: dataGroupList:
02/06:10:47:15: /tvbin/TClient: End SvrResp =======================

02/06:10:47:15: /tvbin/TClient: Connect/POST(s) succeeded
02/06:10:47:15: /tvbin/TClient: Executing HTTP GET: /tvbin/http_get -U http://210.48.107.133:8000/static/Headend/AC-678-v1.slice -D /var/packages -T 02300006023E322 -C 1170758794 -d
02/06:10:47:15: /tvbin/TClient: TFA is 0
02/06:10:47:15: /tvbin/TClient: Not overwriting 1 with 0
02/06:10:47:15: /tvbin/TClient: process411 returned: 0
02/06:10:47:16: /tvbin/TClient: updateStatus: In Progress ST| 34 26
02/06:10:47:16: /tvbin/TClient: SendDialupEvent 30 9 ST|34
02/06:10:47:16: /tvbin/TClient: ServiceInfo DataGroupList attribute was not sent by the service
02/06:10:47:16: /tvbin/TClient: ServiceInfo PublicLogFilter attribute was not sent by the service
02/06:10:47:16: /tvbin/TClient: updateStatus: In Progress ST| 34 26
02/06:10:47:16: /tvbin/TClient: SendDialupEvent 30 9 ST|34
02/06:10:47:16: /tvbin/TClient: Setting NoPrivateBackhaul to 1
02/06:10:47:16: /tvbin/TClient: starting backhaul: 1
02/06:10:47:16: /tvbin/TClient: Setting ServiceInfo ForceBackhaul attribute to 0
02/06:10:47:16: /tvbin/TClient: starting backhaul2
02/06:10:47:16: /tvbin/TClient: starting backhaul3
02/06:10:47:16: /tvbin/TClient: Executing HTTP POST: /tvbin/http_post /var/tmp/syslog.gz http://210.48.107.133:8000/tivo-service/acceptfile.cgi OFF ON
02/06:10:47:16: /tvbin/TClient: updateStatus: In Progress ST| 35 21
02/06:10:47:16: /tvbin/TClient: SendDialupEvent 30 9 ST|35
02/06:10:47:16: /tvbin/TClient: processing timeService: /bin/ntpdate -b 210.48.107.133
02/06:10:47:16: /tvbin/TClient: parsed ntpdate args of -b 210.48.107.133
02/06:10:47:16: /tvbin/TClient: about to run: /bin/ntpdate -b 210.48.107.133
02/06:10:54:50: /tvbin/TClient: updateStatus: In Progress DL| 36 23
02/06:10:54:50: /tvbin/TClient: SendDialupEvent 30 9 DL|36
02/06:10:54:50: /tvbin/TClient: updateStatus: In Progress DL| 38 16
02/06:10:54:50: /tvbin/TClient: SendDialupEvent 30 9 DL|38

The previous otclients are already posted if that helps at all?

[petestrash]

This doesn't appear to be the one which got stuck on setting the time. But it is correctly contacting orac for the time update.

You might want to check with DJC if anyone else is having time issues. We (OzTiVo) are using a newer version of ntpdate which handles timeout better. it may be worth trying as a workaround.

This still doesn't find the cause of your problem, but with both these issues being timeouts from the emulator it looks like a networking issue. You also appear to be the only one with this problem since Dec. It may be worth changing your turbonet setting to failsafe using nic_config_tivo.

Peter.