Adding Slingbox support to RM

[The Robman]

Hey Greg,
I've started playing with this and I'm impressed, things are looking good. There are a few things that still need a bit of tweeking though.

Using the V0616_JU.bin file (ie, VCR/0616 for ReplayTV).

First off, the setup code isn't being captured, it's just showing up as zeroes, and the device type is being displayed as DAT, which isn't a valid device type for the Slingbox. It should be VCR. (Check the RDF in case I set the device types up incorrectly).

The protocol was incorrectly displayed as JVC-48 (rather than Panasonic) but the device codes displayed where correct. So, I changed the protocol to Panasonic, and the device codes disappeared. The JVC-48 and Panasonic protocols use different OEM codes, so you should be able to use those to differenciate between these two similar protocols.

If you try importing the C0476_JU.bin file (for Motorola cable boxes) nothing happens. There's nothing particularly unusual about the data in this file, here's what it looks like...

Code: Select all

0000  40 00 11 dc c4 00 fe fe f6 fe fe ff 00 80 40 c0
0010  20 a0 60 e0 10 90 b0 70 f0 d0 30 50 50 50 98 68
0020  cc 88 c8 28 48 2c ac 6c ec a8 0c 5c dc 1c 9c e8
0030  e4 14 94 54 d4 34 b4 74 f4 1c f8 78 b8 9c 8c c4
0040  4c

If you try importing the V0618_JU.bin file (the official Tivo code), the protocol is displayed as "Acer Keyboard".

Keep in mind, these were the exceptions, most of the files I tried imported totally correctly, and the PL versions seemed to also import correctly, so we're pretty close. I know that alot of Slingbox users are going to be pretty psyched when this is all ironed out, starting with the guys at Sling Media themselves!

[gfb107]

I'll take a look at this later today.

Maybe if the Sling MEdia guys are really psyched they'll send us each a free box!

[johnsfine]

The protocol was incorrectly displayed as JVC-48 (rather than Panasonic) but the device codes displayed where correct. So, I changed the protocol to Panasonic, and the device codes disappeared. The JVC-48 and Panasonic protocols use different OEM codes, so you should be able to use those to differenciate between these two similar protocols.

I assume you both know JVC-48 and Panasonic use the same pid, but the details of how the protocol entry (in protocols.ini) generates the fixed data differ:

JVC-48 specifies the OEM bits only with FixedData=ff 3f 7f ff ff
Panasonic lets the user control those bits through the OEM parameters.

I thought the design of RM in that situation was to translate from the fixed data to the parameters, then translate back and see if fixed data ends up correct. It should end up correct for JVC-48 only if the protocol really was JVC-48. It should end up correct for Panasonic for any pid 00C9.

Is that "translate back" step failing to use the FixedData=ff 3f 7f ff ff info?

The JVC-48 and Panasonic protocols use different OEM codes, so you should be able to use those to differenciate between these two similar protocols.

Rob, the design of RM tries to bury protocol specific rules, such as what you just described, into general use of the translation process. Rather than ever understand that the OEM code is what makes the difference, RM can generically test a sample of fixed data against a protocols.ini entry by using the translation rules in reverse then using them forward. It ends up being the OEM codes that make the difference, but nothing in RM needs to know that.

[The Robman]

I'm confused, doesn't the first half of your post describe what you are repsonding to in the second half of your post (ie, "translate back" step should have picked the right protocol based on the generated OEM and device codes) ?

[johnsfine]

Yes. The first half is technical details of what I thought was supposed to happen. I assume Greg can tell us why it didn't (I'm assuming you are correct about the fixed data not fitting JVC-48)..

The second half was just viewpoint. Your post sounded like it requested a higher level of protocol specific knowledge than we want RM to contain. So I was trying to explain how you get the desired effect by the generic approach (which assumes Greg will fix the generic approach, assuming your results demonstrate that isn't working).

[gfb107]

It's an oversight.

That checking is currently only done when importing a KM device upgrade that uses Device Combiner. That was the only time when protocols were looked up by PID only. In all other cases the lookup is done by name and pid and variant.

[The Robman]

I got some feedback from UEI on this. These are "off the shelf" chips, they weren't put together specifically for Slingbox. Now, having said that, each client that uses these chips has the capability to customize how the buttons are displayed, etc so I think there's still a need to have a seperate RDF for each device (ie, the Slingbox, etc).

So, I think the right way to proceed here is to have a method of tieing an RDF to a chip (when the RDF is for binary files). Maybe we could add something to the RDF name which would tell RM which RDFs are for binary files (without it needing to open them first). I definitely think it would be useful if the chip itself (ie, JU, PL, etc) is specified in the RDF name.

Maybe we need an entry in the RDF that specifies whether the chip uses encryption or not, rather than having that hard coded into RM. It's quite possible that UEI will change the encryption at some point, so this entry could be a number where 0 equals no encryption and 1 equals the PL encryption, then as new encryption methods are used and RM gets updated to recognize them, we can increment this number.

Based on the info above, I don't think there's a need to allow for the three types that you mentioned here, I think just having it look for *.bin files is sufficient, RM would then use the appropiate RDF to determine whether it needs to decrypt the data.

When there is just one matching RDF, it should be selected automatically, but if there are multiple matching RDFs, a selection pop-up could be used to select the right one. (This can be for the future, as we're just dealing with the Slingbox at this time).

So, what are your thoughts?

[gfb107]

Rob,

I've got an update for you to try: RemoteMaster.jar, and an updated protocols.ini.

The problem importing the TiVo upgrade was a difference in how the unit code was stored in the fixed data. THey way we coded protocols.ini, we stored an 8 bit value in the 3rd byte, LSB comp. UEI stored a 4 bit value in the first nibble of the 3rd byte byte, LSB-COMP, and defaulted the last nibble to 0.
So, in UEI's upgrade, a unit code of 0 was stored as F0. When RM imported that value, it got a unit code of 240!. The fix was a simple change to protocols.ini. I changes the default fixed data, setting that last nibble to 0, and changing the unit code field to be 4 bits instead of 8.

[The Robman]

Greg, this is looking good. I re-imported all the bin files that had had problems and they all worked perfectly.

However, I notice that when you change the selected protocol, all of the device codes vanish. To prevent this, I need to type over each of them before trying a different protocol.

Just out of curiosity, I tried importing the Y0525_JU.bin file (for DVD/0525). As this is a very new version of the code, it uses what we cann the "Pioneer MIX 4-cmd" protocol. This isn't in protocols.ini under that name, so it's not a selectable protocol. I see that there is a version of "Pioneer MIX" in protocols.ini that has 6-bytes of fixed data, so that's the protocol in question. Do we need a new protocols.ini entry for the 4-cmd version?

When I import the DVD/0525 file, the auto-selected protocol is "Pioneer DVD". I would need the ability to change that to "Pioneer MIX 4-cmd" for the fixed data to line up correctly. Actually, that makes something else occur to me that might complicate this a bit. Because RM won't always get the protocol select 100% correct (especially in cases like when the protocol is $007E and there are many variants of it), before the user is thrown into regular RM, there should be the opportunity to change the selected protocol and have the data re-allign. In this case, RM thinks that there are only 3 bytes of fixed data and 1 byte of variable data (whereas in fact, there are 6 bytes of fixed and 2 bytes of variable). Can you think of anyway where I would be able to change the selected protocol (assuming that we had an entry for the 4-cmd version) and RM would re-allign everything? At some point, the "import" process should be complete, whereby any changes made afterwards are simply changes and RM would not have to re-allign anything. This would probably also apply to the "Import Raw Upgrade" function.

Also, while I was testing, I noticed something strange. It appears that once you open an RMDU file, you have 4 chances to change the selected protocol. After that, even though you change the selected protocol, the protocol id, fixed data, etc do not change. At this point you need to close down RM and start it again.

Finally, the Acer/Tivo mix-up got me thinking, so I took a look in protocols.ini and discovered that the pid for the Acer Keyboard is $0111. Does anyone remember where this came from? I ask because $0111 is the official Tivo protocol id.

Hope this is all helpful. Thanks again for your effort on this Greg, it's much appreciated!

[gfb107]

We certainly do need a protocols.ini entry for the 4-cmd version.

Right now RM doesn't have all the information it needs to select the correct protocol. Specifically, the RDFs says there are NO protocols built-in. Which isn't true. If RM knew which variant was built into the remote, it should use that one.

I'll look into what's going on with the device parameters when the protocol is changed. I know that there is no coded limit, but I suppose that depending on which protocols are selected you might lose one or two parameters each time you switch. It'll be a couple of days, though.

[gfb107]

OK, I found some bugs in the code that handles device parameters when changing the selected protocol.

Let me explain how it works.

When the protocol is changed the code assigns the device parameter values from the old protocol to the new protocol by matching the names of the device parameters. If there is no device parameter with a matching name, the value is not copied and is lost.

As protocols.ini stands today, JVC-48 has

Code: Select all

DevParms=Main Device,Sub Device

while Panasonic has

Code: Select all

DevParms=Device=144,Sub Device=0,OEM Dev1=2,OEM Dev2=32

So when the protocol is changed from Panasonic to JVC_48, the only parameter that is preserved is Sub Device. Of course, changing the name Main Device to Device for JVC-48 will mean the Device is also preserved, but OEM Dev1 and OEM Dev2 will be lost because there is no place to hold their value.

Here's another RemoteMaster.jar and protocols.ini.

[johnsfine]

I think this is another case where using reverse translation from fixed data would help RM do better conversions.

In the complicated family of Kaseikyo protocols with the Panasonic check byte, we have several pids and several meanings for each pid (Pansonic and its combos, and JVC-48 and Denon-K, and I expect this nest of interelated protocol.ini entries will grow).

I'm not certain how much it should matter whether pid and varient match and I'm not sure which approach should win when they conflict. But I suggest:

1) Assuming the fixed data length is the same, RM should do an initial reverse translation of the old fixed data based on the new protocols.ini entry.

2) Certainly if pid or varient is different, and probably even if they're the same, RM should follow with what you described above (copy named parameters for which the names match). So the results of (1) are only left in places where the names don't match.

[The Robman]

Thanks for your continued efforts on this Greg. I will try out this new version when I get home. Regarding the device code thing, rather than tieing the values entered to the displayed names (ie, "Main device", "device", etc) you could give each box an internal name and tie the values to those. Then, even when the protocol is changed, the values will remain. And if a protocol is selected that has less variables, and then the original protocol is re-selected, the values won't be lost because they would be held in the internal items.

Seeing as how we've discovered that the chip used in the Slingbox is not unique to the Slingbox, but is a standard "off the shelf" UEI chip, where the tag (ie, PL, JU, etc) tells us which version it is, have you given any more thought to having the RDF tied to the tag in some way?

The RDF could also tell RM whether the chip is encrypted or not, and possibly which encryption is used. I don't know whether it's possible to reduce the encryption to code that can be placed in the RDF itself, but if it is possible, that would be even better. So if and when a new version of the chip is produced that uses a different encryption, we could handle it in the RDF without needing to change the RM code.

[gfb107]

John,

That's a reasonable idea, but there are issues.

When RM imports fixed data, it uses the device translators to extract device parameter values from the fixed data, which is what it remembers. The actual fixed data is not stored.

Now, let's look at what would happen when switching from Panasonic to JVC-48 (assuming the mismatch naming of the first device parameter).

When importing the fixed data from Panasonic, JVC-48 only has 2 device translators, which would correctly import the Main Device and Sub Device, but still would not import the OEM devices. This is an improvement over the current design.

Then when copying the device parameters by name, the Sub Device would be copied again (which is fine).

Now, let's switch back to Panasonic again.
First we get the fixed data from JVC-48, which is computed from the stored device parameters and the FixedData from protocols.ini, which has hard coded values for OEM Dev1 and OEM Dev2
Panasonic has device translators for Device, Sub Device, OEM Dev1, and OEM Dev2. These would all get imported from the fixed data, resulting in the hard coded values from JVC-48 being used.

Then, the Sub Device would get copied by name again (still fine).

So, your proposal would improve the cases where we have used slightly different names between related protocols, but wouldn't solve the problem entirely.

[johnsfine]

When RM imports fixed data, it uses the device translators to extract device parameter values from the fixed data, which is what it remembers. The actual fixed data is not stored.

I was assuming that would be OK because it should be happening in a protocols.ini entry that is fully compatible with the original generation of that fixed data.

Now, let's look at what would happen when switching from Panasonic to JVC-48 (assuming the mismatch naming of the first device parameter).

Obviously the OEM values must be lost. If the lost values didn't match the JVC values then the user can't help changing the meaning of the upgrade when switching to JVC-48. But in that case, what did he intend if not changing the meaning.

Now, let's switch back to Panasonic again.
First we get the fixed data from JVC-48, which is computed from the stored device parameters and the FixedData from protocols.ini, which has hard coded values for OEM Dev1 and OEM Dev2
Panasonic has device translators for Device, Sub Device, OEM Dev1, and OEM Dev2. These would all get imported from the fixed data, resulting in the hard coded values from JVC-48 being used.

The "back to ... again" emphasizes a scenario that I think is too hard to support. If the user switches and then switches back or again, he can't expect to reliably end up where he would have been without that first switch. Information can be lost. The user should keep backup copies rather than use a second switch to undo an incorrect first switch.

But if the user started in JVC-48 there may be legitimate reasons to switch through the more general Panasonic. In that case we want the JVC OEM values to get into the resulting upgrade.