[telemark]

That's a reasonable request, but I'd be surprised if they overhaul this API since they don't use it themselves much.

On using an intermediary, do you get to set the IP and Port# of the Tivo, or does it force you to use auto-discovery?

The easiest way to do this is to rewrite the driver on the remote. Is that opensource / viewable anywhere?

 

[telemark]

I like how the spec PDF talks as though multiple clients can be connected at once.

ha, I'd like it more if they followed their specs.

I'm actually kinda concerned the relevant software engineers are long gone and they're too afraid to touch their old code base.

I would suspect opening and closing the connection after every command would introduce a lag.

Maybe, but maybe it won't be enough to notice. I can say every IP remote I've tried is faster than any of my IR remotes.

It's not impossible to write, but intricate. It's like this homework assignment, for CS juniors/seniors.
(They get a week. I assume a pro could do it in a day)

Could you run this test on your mac, to see if the iRule remote requires bidirectional communications to work. Because this test uses a pipe, the responses from the Tivo won't be sent back to the remote.
nc -l 31339 | nc TIVO_IP 31339
(Point the remote to the mac, and the command line to the Tivo's IP)

Maybe you know the answer already, does the app display channel status?

 

[telemark]

Wow, impressive. I was only contemplating a one-way version.

It does look fun, simple problem statement, non-obvious complexity, but compact implementation.

In Python, it does come out more elegant (because of light threads). Good choice there.

Very cool.

 

[telemark]

Now with its own proper home:

http://wmcbrine.com/tivo/#rproxy

This version adds autodetection and selection of TiVos, as a command-line option -- use -i for interactive mode. It also fixes some crashes with Network Remote 0.29.

I'm trying to start this from scripts.

Can we make autodetection mode, non-interactive. (I only use one tivo so it's always #1).

Something like this might make it universal:
-f "Living Room"

 

[telemark]

..and for less techy types, like myself, where do you put the .py files to avoid having to include the directory path in the command?

For the options, Run:
echo $PATH

/usr/local/bin/
is a pretty standard choice.

You might also want to set the permissions, with:
chmod +x /usr/local/bin/*.py

then you don't have type python, just:
rproxy.py

 

[telemark]

I'll chime in some talking points...

It's possible to put a retry that would attempt to connect after a Tivo restart, assuming its IP didn't change.

A couple examples makes it debatable if this is the best way to handle it.

What if the Tivo wasn't restarted but was switched off? Shouldn't the proxy exit instead of hanging around? Then how to tell the difference?

Even if the Tivo's coming back, is it fair to the connected clients to accept commands that won't be sent out.

Haven't fully thought it through, but I'm guessing it would be cleaner to exit whenever a Tivo goes missing. Then either external or internal controls should restart it (if desired) to a state of waiting around for a good broadcast.

And disclaimer: my opinion doesn't matter, while wmcbrine's does.

 

[telemark]

This is the smallest patch I could find against 0.5, that will cause rproxy to exit when it gets a network error back from the Tivo.

If you set Lingon to "Always", rproxy should exit when the Tivo is back up, and Lingon will restart it.

Turning off the Tivo for an extended time might eventually cause undesirable behavior on the Mac, as described earlier but really depends on how Lingon is written.

# diff ~/rproxy0.5/rproxy.py /usr/local/bin/rproxy.py 
282,283c282,283
<     thread.start_new_thread(status_update, (tivo, listeners, target, verbose))
<     serve(queue, listeners, host_port)
---
>     thread.start_new_thread(serve, (queue, listeners, host_port))
>     status_update(tivo, listeners, target, verbose)

Edited: a second patch that reintroduced KeyboardInterrupt detection

 

[telemark]

Yes, as long as they have python available, which if they're running linux should be available.