Adding Slingbox support to RM

[gfb107]

The more I think about it, the less it makes sense to put these in the RDFs, since the same values will always be used. I suppose I'll just put it in the code for generating the binary upgrade files.

[The Robman]

But if RM has no concept of device types, how will you know what types to associate each letter with?

[The Robman]

Greg, how are you handling protocols for the bin files? As I haven't completed the [Protocols] section of the Slingbox RDF yet, is RM including a protocol with all upgrades when you use the export to bin option? If it isn't, it probably should. Then to prevent that, we'll need to add most of the protocols to the RDFs until such time that we can acurrately determine which ones are really built in and which ones are not.

[gfb107]

At the moment I am not including the protocol. That'll be easy to add.

[The Robman]

OK then, leave it as is for now, until I can get something to put in the RDFs.

[gfb107]

But if RM has no concept of device types, how will you know what types to associate each letter with?

Once again, it'll just be a string lookup. RM knows the name of the device type, and can use that to find the abbreviation. So I'll just code the abbreviation look up table as you've documented above. If no abbreviation is found, I'll just use the whole name.

[gfb107]

I noticed there's no abbreviation for DVD? I think it's Y, based on some of the .bin files you've shared. I think there are others missing as well. Aren't there 15 possible device types?

[The Robman]

Once again, it'll just be a string lookup. RM knows the name of the device type, and can use that to find the abbreviation. So I'll just code the abbreviation look up table as you've documented above. If no abbreviation is found, I'll just use the whole name.

But what I was gettng at is this, suppose one RDF calls the Cable mode "CBL" and another calls it "CBL/SAT" and yet another calls it "Cable", how will RM know that they are all "Cable" and should use the "C" letter? That's why I actually came around to your original way of thinking, once you reminded me that RM doesn't know device types.

I noticed there's no abbreviation for DVD? I think it's Y, based on some of the .bin files you've shared.

Sorry, I must have skipped that line for some reason. I've edited the original post to include DVD, and yes, it's "Y".

I think there are others missing as well. Aren't there 15 possible device types?

There are only 10 types in this chip. It's missing the following types: Phono, Cassette, DAT and Misc Audio. I don't know what the letters are for each of those types, but I can probably find out.

[gfb107]

OK, I'm back to putting it in the RDF.

I have a question though. It looks to me like it isn't the device type but the device type alias that is being abbreviated. I say this because Laserdisc isn't a device type, it's a device type alias (at least in the Slingbox RDF).

Assuming it is for the device type alias, we can just enhance the syntax of the DeviceTypeAliases section, 'cause I'm pretty sure IR doesn't use it.
We'll just append the abbreviation after the alias name, with a colon separating the name from the abbreviation.

Like this:

Code: Select all

[DeviceTypes]
Cable    = 1,1
Sat      = 2,3
VCR      = 3,4
DVD      = 4,6
CD       = 6,9
Audio    = 5
TV       = 0

[DeviceTypeAliases]
Cable    = Cable:C,Video Acc:N
Sat      = SAT:S
VCR      = VCR:V,Tape,Laserdisc:L,DAT
DVD      = DVD:Y
CD       = CD:D,Home Auto:H
Audio    = Tuner,Misc Audio,Phono,Amp:AM
TV       = TV:T

If no abbreviation is provided in the RDF, the full alias name will be used instead.

Thoughts?

[The Robman]

I have a question though. It looks to me like it isn't the device type but the device type alias that is being abbreviated. I say this because Laserdisc isn't a device type, it's a device type alias (at least in the Slingbox RDF).

Even though the Slingbox doesn't support those device types, the chip does. As mentioned earlier, I still need to add all the missing device types and keymaps to the RDFs. I didn't know these other types existed when I created the RDFs, so I lumped them in with the supported device types.

So, bottom line, they are real device types. The ones that would still be mixed in are the 4 missing ones.

[gfb107]

OK, so we'll just have to add a new section to the RDF. We'll call it DeviceAbbreviations. It will contain a comma separated list of the form type name=abbreviation. For example:

Code: Select all

[DeviceTypes]
Cable    = 1,1
Sat      = 2,3
VCR      = 3,4
DVD      = 4,6
CD       = 6,9
Audio    = 5
TV       = 0

[DeviceAbbreviations]
Cable=C,Sat=S,VCR=V,DVD=Y,CD=D,TV=T

Note: In my example, created using the device types in the Slingbox RDF, I didn't know the abbreviation for Audio, so I just left it out.

[gfb107]

Here's the latest test version of RemoteMaster.zip. This time it's a zip file, which contains RemoteMaster.jar and an rdf directory containing the two Slingbox RDFs. The RDFs should be copied to the directory where RM is configured to look for RDFs.

I've added support for parsing the DeviceAbbreviations section of the RDF, as described above. This is used for generating the default name for the exported binary file.
I've also added the ability to include protocol code in the exported binary file. This is disabled by default, but can be enabled in the Options menu. Once enabled, RM will remember it until it is turned off.

[gfb107]

On a whim, I've created an image and map for the Slingbox. I've zipped them up into SlingboxMap.zip.
Unzip it in the same folder as RM, so that the .map and .jpg end up in the images sub-folder.
You'll also want to change the RDF to point to the new .map file:

Code: Select all

ImageMap=Slingbox.map

The image is a composite I created of the SlingRemote from the User Guide.

[The Robman]

The new Slingbox images look good. However you need to tweek the new file name logic because it's dropping the leading zero from the setup code when the setup code is less than 1000.

[gfb107]

Oops.