Number not available

[worm]

Code: Select all

[TiVo [p0] /var/tmp]# /tvbin/tclient_post 127.0.0.1:8000 /var/tmp/HServer.send /var/tmp/test.recv 5 ON
Wed Jun 29 23:31:04 2011: /tvbin/tclient_post invoked
 connecting to 127.0.0.1:8000
 connect failed, reason = Connection timed out
 connect failed, reason = Connection timed out


[worm]

Which looks to me like the connection to the emulator process is failing in some way.

[spitfires]

According to what you posted here

Code: Select all

 164  ?  SW   0:00 /var/hack/bin/emuProxyZA -s 194.1.151.205 -p 80 -d2


you have the emulator running on port 80 not 8000 !

Edit the file /etc/oztvo.conf & change

Code: Select all

emulatorport=80

to

Code: Select all

emulatorport=8000

& reboot.

[worm]

aha!

but .... nope, still fails (quicker this time... )

Code: Select all

06/30:13:42:02: /tvbin/TClient:  Executing HTTP command: /tvbin/http_post /var/log/svclog http://127.0.0.1:8000/tivo-service/mlog.cgi OFF OFF ON
06/30:13:42:03: /tvbin/TClient:  Failed while POSTing downloaded files stats:  error reading HTTP header, reason = Broken pipe
 error reading HTTP header, reason = Broken pipe


Shouldn't I (in some way) change the call so it looks for the emulator on port 80 rather than changing the emulator to port 8000? Does changing it to 8000 not change the port the emulator actually uses to connect to the server?

[spitfires]

Oh yeah - aren't I a silly boy! Totally the wrong end of the stick there Please ignore what I said 2 posts ago and put your .conf back the way it should be It's the heat you know - it's melted my sole remaining brain cell. Sorry

[worm]

easily done

now, anyone know how to make the actaul call use port 80 rather than 8000 (if that's the right thing to do)? and why is mine different? argh!

[spitfires]

Your setup seems correct - Daily Call is asking for data from the proxy on port 8000 :tick: which then fires off the request to the server on port 80 :tick:

You've proven that you can talk to the server on port 80 so the issue is with the proxy timing out when it communicates with the server. Have to wait for millsb to get home from work...

[healeydave]

Your setup is correct.
emuProxy sits on the Tivo listening out on the loopback IP 127.0.0.1, port 8000 for http traffic to the AltEPG server.
emuProxy intercepts http posts received, and reformats them to be compliant to http 2.0 and then passes them onto the destination (which is the AltEPG server on IP 194.1.151.205, port 80).

So think of emuProxy as a translator.
oztivo.conf is the configuration of your Network settings, correctly advising the emulator and port address of the AltEPG server.
tclient.conf tells the system where to direct traffic based on the Dial-In Code selected in phone settings.
So, 127 points to IP 127.0.0.1, port 8000 (which is emuProxy).
emuProxy translates the posts and sends them back off on their way to the AltEPG Server on IP 194.1.151.205, port 80

[worm]

Yeah, makes sense. It's all very odd.

The first part seems to work (TCD 411)

Code: Select all

06/30:14:02:00: /tvbin/TClient:  Executing HTTP command: /tvbin/http_post /var/log/svclog http://127.0.0.1:8000/tivo-service/mlog.cgi OFF OFF ON
06/30:14:02:01: /tvbin/TClient:  about to do TCD411 Call
06/30:14:02:01: /tvbin/TClient:  Executing HTTP command: /tvbin/tclient_post 127.0.0.1:8000 /var/tmp/TCD411.send /var/tmp/TCD411.recv 300 ON
06/30:14:02:02: /tvbin/TClient:  doHttpCall returned: 1
06/30:14:02:02: /tvbin/TClient:  reading HTTP header...
06/30:14:02:02: /tvbin/TClient:  HTTP header: HTTP/1.1 200 OK
06/30:14:02:02: /tvbin/TClient:  HTTP header: Date: Thu, 30 Jun 2011 14:02:00 GMT
06/30:14:02:02: /tvbin/TClient:  HTTP header: Server: Apache/2.2.14 (Ubuntu)
06/30:14:02:02: /tvbin/TClient:  HTTP header: Vary: Accept-Encoding
06/30:14:02:02: /tvbin/TClient:  HTTP header: Connection: close
06/30:14:02:02: /tvbin/TClient:  HTTP header: Content-Type: text/plain; charset=ISO-8859-1
06/30:14:02:02: /tvbin/TClient:  Got end of Header
06/30:14:02:02: /tvbin/TClient:  TCD411RespCli::readBlock returned: 1
06/30:14:02:02: /tvbin/TClient:
06/30:14:02:02: /tvbin/TClient:     Start TCD411Resp =====================
06/30:14:02:02: /tvbin/TClient:              errMsg:
06/30:14:02:02: /tvbin/TClient:         areaCodeObj: OK
06/30:14:02:02: /tvbin/TClient:        tollFreeAuth: 0
06/30:14:02:02: /tvbin/TClient:         tollFreeNum: 0
06/30:14:02:02: /tvbin/TClient:       End TCD411Resp =====================



but the second part (HServer), not so much.

Code: Select all

06/30:14:02:02: /tvbin/TClient:  about to do HServer Call
06/30:14:02:02: /tvbin/TClient:  Executing HTTP command: /tvbin/tclient_post 127.0.0.1:8000 /var/tmp/HServer.send /var/tmp/HServer.recv 300 ON
06/30:14:07:02: /tvbin/TClient:  http POST command failed:  timeout waiting to read
06/30:14:07:02: /tvbin/TClient:  doHttpCall returned: 0
06/30:14:07:02: /tvbin/TClient:  Connect/POST has failed, we've warned the user, set status to Failed


[healeydave]

cold start the tivo and try again and I'll check the log on the server.

[Edit]
Yes, if its your "Living Room" tivo, according to the server log, the last successful connection was Sat 25th July.

[worm]

Yeah, I think that was when it claimed to work but then failed on indexing.

Actually, now I think of it, I've not done Guided Setup on this restored image - just tried a Daily Call, and the system is currently showing as 5: Lifetime service.

Does it need to be on 4: Testing to complete the call? If so, is there any way to do that without going through Guided Setup? I tried a Test Call but that didn't work. Because if I get into Guided Setup and can't complete it, the only way to get out and sort it is to pull the disk and re-image it, which is a bit of a pain to be honest.

[healeydave]

Its showing status 5 because you ran the fixup hacks and it hasn't made a successful call to the server since.

As soon as it makes a successful call, even just a partial successful call or a test call the account status will be updated to status 4.
The current hacked status doesn't really matter, because the tivo gets its real status from the server.

I would recommend once you get a test call to connect ok, you do a C&D of some sort and then a GS.

[worm]

As long as it's not just failing because of wrong status. Doesn't solve the problem, but rules out one possible issue.

[healeydave]

No, the server takes no notice of what status the tivo thinks it is, rather on successful call, the server tells the tivo what status it really is

[worm]

So, anyone got any clever ideas?