Multiple Network Remotes

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?

 

Some of the remote programs (note: not mine) will open a connection, send a command, and then close the connection again. One of these would allow pseudo-simultaneous use with another instance.

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

 

Advertisements

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.

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?

 

It has amused me to write this program for you. Actually, this is going to come in handy for me, too... I should've done it long ago, if only I'd thought of it.

This is a barebones version... unzip it, open a Terminal window, and type "python rproxy.py your.tivo.ip". Then point your remote apps at the computer's IP. If you're not comfortable with that, I'll probably post a GUIfied version later, with autodetection, etc. Anyway, it works as-is.

 

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.

 

Updated version -- still no autoconfig or GUI, but I wanted to post this cleaned-up and documented version first.

- Verbose mode, logs to the console
- Host/port options
- Queue.Queue instead of a list (thanks telemark)

 

Nice! This is great work, wmcbrine!

TonyBlunt, whaddaya think?

 

Must be an iPad thing. I have two Android tablets, both with a Tivo remote app present. Both work fine. I have not tried using both simultaneously, sending competing commands. Both had to be loaded with the Tivo's MAK.

I only have one Tivo so I can't test, but it looks like the Android app could switch between multiple Tivos, too.

 

No, it's not an iPad thing. It's not about having remote apps installed on two different systems, it's about having them actually open and connected to the same TiVo at once.

Also, the problem described here applies to the older, port 31339 "Crestron" protocol, as used by most third-party remote control apps. It may or may not apply to the newer system used by TiVo's own Android and iOS apps (and by KMTTG); I haven't tested that.

 

TiVo has no incentive to add this "feature", since it's designed for Crestron or Control 4, where the control system would manage various controllers, and then relay one set of commands via IP to the TiVo.

 

This version adds announcements via Zeroconf, for remote apps that scan the network for available TiVos. It also shows the address and port in verbose mode, and is slightly reorganized.

The name used for the announcements is "Proxy(tivoname)", where "tivoname" in turn is derived from a Zeroconf scan. (If that fails, the IP address is used.) This format is recognized by my Network Remote v0.29 or later, and used to remove the original TiVo from its connection list (since it's "busy"). Older versions of Network Remote lack this feature, and are limited to port 31339 (like real TiVos, but unlike rproxy), but are otherwise compatible, and will recognize rproxy's announcements and connect to it.

 

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"

 

You probably ought to give the TiVo a static IP in that situation. But, sure, I could do that...

 

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

Version 0.5 allows you to specify the TiVo by name (i.e. the display name, like you'd see in the "My Shows" list or via -l) or TiVo Service Number, as well as by IP. (Similar to telemark's suggestion, but no option flag is needed.) Also, there's a new option "-f", to simply scan and connect to the first TiVo found. Also, specifying the port to connect to on the command line hadn't actually been working.

 

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