So I've been playing around with telnet commanding and status with my TivoHD, and I keep getting network drops that I can't seem to recover from. When the activity first loads, things work fine for a while, which may be anywhere from a couple minutes to more than half an hour. But invariably, at some point, things stop working.

I am fairly sure the issue is with the Pronto, not the Tivo, because 1) other tools including putty and a control util written by someone at tivocommunity work fine and do not disconnect. 2) I can usually re-establish comms by going to the home page and back to the tivo activity, at which point things again work for a while.

The TivoHD telnet feature is described here (not sure there's any official documentation yet...):
[Link: tivocommunity.com]
It is nowhere near as comprehensive as, say, the Denon protocol (working fine via telnet for me, incidentally), but it does allow basic commanding and retrieving channel and recording status.

I've tried a variety of page timers, scheduleAfter, etc. to monitor/keepalive, but no luck. I've tried with the Tivo and pronto on the same subnet, which is not how I normally have things configured, but no luck with that either. If anyone has any suggestions, I'd love to hear them.

Thanks,
Eric

Here is the code as it stands now. This is eval'ed at the activity level and kicked off by calling connectionSetupTivo.


// Tivo Comms

// Global vars

var socketTivo = null;
var socketStatusTivo = "down";

// Response processing =====================================================

function processInputTivo(sString)
{
var tmpString;
var aResults = sString.split(String.fromCharCode(13));
var i;

for (i=0; i{
tmpString = aResults[i];
System.print(tmpString);
if(tmpString.substr(0,9)=="CH_STATUS" && CF.widget("TIVOCHANNEL")) {
CF.widget("TIVOCHANNEL").label = "Ch: " + parseInt(tmpString.substr(10,4),10); }

if(tmpString.substr(0,9)=="CH_STATUS" && CF.widget("TIVOCHANNELREC")) {
CF.widget("TIVOCHANNELREC").visible = (tmpString.substr(15,3) == "REC"); }

}
}



// Connection handling ===================================================

function onConnectTivo()
{
System.print("Tivo: Connected");
socketStatusTivo = "up";
if (CF.widget("SOCKET_CLOSE","PS_SYSTEM","PS_SYSTEM"))
{ CF.widget("SOCKET_CLOSE","PS_SYSTEM","PS_SYSTEM").label = ""; }
if (CF.widget("SOCKET_ERROR","PS_SYSTEM","PS_SYSTEM"))
{ CF.widget("SOCKET_ERROR","PS_SYSTEM","PS_SYSTEM").label = ""; }
}


function onDataTivo()
{
var myString;
System.print("Tivo: Received Data");
socketStatusTivo = "receiving";
myString = socketTivo.read();
processInputTivo(myString);
}


function onCloseTivo()
{
System.print("Tivo: Connection Closed");
socketStatusTivo = "down";
socketTivo=null;
if (CF.widget("SOCKET_CLOSE","PS_SYSTEM","PS_SYSTEM"))
{ CF.widget("SOCKET_CLOSE","PS_SYSTEM","PS_SYSTEM").label = "T"; }
}


function onIOErrorTivo(e)
{
System.print("Tivo: Connection Failed");
System.print("Tivo: " + e);
socketStatusTivo = "error";
socketTivo=null;
if (CF.widget("SOCKET_ERROR","PS_SYSTEM","PS_SYSTEM"))
{ CF.widget("SOCKET_ERROR","PS_SYSTEM","PS_SYSTEM").label = "T"; }
}


function connectionSetupTivo()
{
System.print("Tivo: Setting Up");
socketStatusTivo = "pending";
if (socketTivo && socketTivo.connected) { socketTivo.close(); }
socketTivo = null;
socketTivo = new TCPSocket(false);
socketTivo.connect("192.168.5.199",31339,3000);
socketTivo.onConnect=onConnectTivo;
socketTivo.onData=onDataTivo;
socketTivo.onClose=onCloseTivo;
socketTivo.onIOError=onIOErrorTivo;
}



// Send commands ========================================================

function sendCommandsTivo(cmdList)
{
var cmd;
var i;

if (socketTivo && socketTivo.connected)
{
for (i=0; i{
cmd = cmdList[i];
System.print("Tivo: Sending: " + cmd);
socketTivo.write(cmd + "\r");
System.delay(25);
}
}
else
{
if (socketStatusTivo !== "pending")
{
connectionSetupTivo();
}
scheduleAfter(250,sendCommandsTivo,cmdList);
}
}

Eric,

Your experience with the Tivo/Pronto matches mine exactly. I believe it is related to the socket closing because of power saving mode in the Pronto. When left in the base, it seems to run just fine.

I'll be very interested in any suggestions on this. The Tivo telnet functions make repetitive button presses much faster than the IR control, so this is really something I want to get functioning 100%.

- Jon

Interesting observation. I'll test that with my setup.

The ProntoEdit simulator never loses connection either, so it really must be an issue with the remote itself. Hopefully someone here can point us in the right direction with some error trapping/retry logic that will remedy the situation!

I recommend one, or a combination, of some approaches that is common in the IP world:

- close the socket deliberately after not sending a user-interactive command for a while, re-opening only when user-interaction is apparent (ie, have a call that you can make in various places so you know interaction occurred and thus the thing is awake

- only keep the socket open for the duration of anything you do (like with http). obviously this will have a latency impact for repeated interactive commands

- implement a keep-alive & retry. any command you send, give up if you don't get a timely response (ie, because pronto is still waiting for the TCP session to fail) and then close/open the socket and try again. you're basically defeating TCP's inclination to try to recover, which it won't if the tivo closed the connection whilst the pronto is asleep. pronto will resend TCP segments, tivo will ignore them because it has no record of the session the pronto is talking about.

Chris.

As I mentioned above, I've tried a variety of methods along those lines - periodically close and re-open the connection, check and retry before each command, etc.

The problem is, they all work for a while, and then don't work at all. So once the connection drops, no amount of close/re-open attempts or anything will restart it. The onClose and onError callbacks are sometimes triggered, but sometimes not. Leaving the activity and coming back to it is the only way to (usually) restart the connection.

You may be running out of sockets, if they don't close properly. Catch exceptions on all socket operations and print them all. I had similar and found that when connect fails it doesn't always close the socket (open but not connected, or some such), for instance.

Chris.

There is absolutely no way to tell that the Pronto is "asleep". The pronto definition of asleep is that the processor is stopped, ergo no way to tell since the processor must be running to do/tell anything!

What you can tell is that you were "asleep". To do that you need to use the clock in a known loop to see how long the loop iteration took. You can then make a judgement that the loop took way to long ergo the processor must have stopped, but it is not stopped now!. Also the Pronto never stays "asleepA for more than about 57 seconds. It then wakes up for about 5 and then goes back to sleep. In real terms, since ascribing terms like sleep and awake is just anthromorphising (assigning human characteristics to non human entities), the processor is stopped when it detects nothing is going on and the processor restarts about every 57 seconds or so and then stops again 5-7 seconds later. While the processor is stopped the real time clock is ticking away, so the only way to see that you are in the restart period is by checking the clock while in a repetitive loop like a page loop.

Hope that helps someone.

That certainly seems consistent with the symptoms. But shouldn't setting the socket to null before trying to use it again prevent that? I check for a valid connection, close it, and set the socket to null prior to trying to create it again. e.g.:

function connectionSetupTivo()
{
System.print("Tivo: Setting Up");
socketStatusTivo = "pending";
if (socketTivo && socketTivo.connected) { socketTivo.close(); }
socketTivo = null;
socketTivo = new TCPSocket(false);
socketTivo.connect("192.168.5.199",31339,3000);
socketTivo.onConnect=onConnectTivo;
socketTivo.onData=onDataTivo;
socketTivo.onClose=onCloseTivo;
socketTivo.onIOError=onIOErrorTivo;
}

Thanks,
Eric

What I have done before, roughly:

try {
  sock.connect(host, port, 3000);
} catch(e) {
  sock.close();
}

Setting the "sock" to null does not guarantee immediate (or even 'soon') destruction, and thus no cleanup.

Chris.