RM Setup Codes.

[The Robman]

I haven't yet tried to bypass the file name check, since I don't know what the which bits need to be off or on in the device id for setup code. The idea of uploading 16 different files doesn't seem very fun at the moment. Maybe someone will enlighten me which binary combination will represent the laserdisc in the device ID.

Just remember that I told you that this isn't the way to go about it, not that I can stop you. The L9999 code is obviously a special code that tells the Slingbox that the file contains learned signals and therefore the file is not in the conventional upgrade format. So, in my humble opinion, trying to make an upgrade file that has L9999 as it's name, if that were even possible (which it isn't) would be pointless.

[eferz]

I appreciate your input, Rob. I'm not ignoring you but it seems you're still under the assumption that I'm trying to sneak in a remote upgrade as learned signals. That's not my intention at all.

Actually, I'm trying to sneak in a blank file to see if it will affect the codes that I've learned. Trying to figure out the storage schema for the new process. I'm more interested at this point trying to figure out how the data is being assimilated and if it stored the same way as standard bin files.

From my current understanding, standard bin files are stored in common container. If the setup code matches more than one input it will affect any of the three inputs for each of remote profiles; Component, S-Video, and Composite. This caused a severe limitation of independent control of multiple similar devices, regardless if it had address pairing.

For example, if someone had a multimedia closet and multiple DirecTV or Dish Receivers then they problems trying to control individual boxes. At first, we thought each input had its own branched storaged container. Then we realized if multiple inputs used the same code then the remote would take the characteristics of the last update.

Then we realized we could separate control by assigning a unique setup code for each of the inputs. Unfortunately, this cause a lost of the use for the stylized remote across all inputs. Instead only one input could have the stylized remote, the rest had to be generic remotes. This is because the stylized skin would only load based on specific setup code association. Later, we realized that some skins had multiple associations. Now we have a list of over 55 remote skins and a listing over 75 setup code associations.

However, that knowledge didn't come without a lot of tedium and persistence. So, understanding how the data is stored is more important to me than uploading a working remote profile. Theoretically, If I wanted to get a working "L9999" remote into the Slingbox, it might be easier for me to spoof the web page that stores the XML file with the UEI learned codes. Then all I would need to do is queue the Slingbox to translate and download the XML from the spoofed page. But, that's not what I'm after at this point.

[The Robman]

I appreciate your input, Rob. I'm not ignoring you but it seems you're still under the assumption that I'm trying to sneak in a remote upgrade as learned signals. That's not my intention at all.

Then why are you looking to find a device type that will help you generate the L9999 setup code/file name?

[eferz]

Actually, I'm trying to sneak in a blank file to see if it will affect the codes that I've learned. Trying to figure out the storage schema for the new process. I'm more interested at this point trying to figure out how the data is being assimilated and if it stored the same way as standard bin files.

I know the filename won't be be generated as "L9999" but that's a limitation of Remote Master. It assumes the setup code is limited to 11-bits. However that isn't to say the upload tool reads the two bytes the same way its produced. Besides, it is much easier to rename a filename than it is to change the setup code within the file.



Uploaded with ImageShack.us



Uploaded with ImageShack.us

[The Robman]

I know the filename won't be be generated as "L9999" but that's a limitation of Remote Master.

It's not a limitation of Remote Master, it's RM enforcing the Slingbox rules.

[eferz]

Okay, that makes sense... since I'm trying to bend the rules.

[gfb107]

It highly unlikely that the contents of a L9999 bin file looks anything like the contents of a 'standard' Slingbox bin file. We suspect the slingbox is keying off the file name instead of the file contents, Given that 9999 is an invalid setup code.

By their very nature, bin files (which are really reformatted device upgrades) must include a device type and setup code. Those concepts are totally irrelevant for learned signals, so it would make no sense to embed those in a learned signal file.

We know exactly what the format of a 'standard' bin is, and we also know exactly the format of learned signals. There is no similarity.

[eferz]

It highly unlikely that the contents of a L9999 bin file looks anything like the contents of a 'standard' Slingbox bin file. We suspect the slingbox is keying off the file name instead of the file contents, Given that 9999 is an invalid setup code.

I can do one better and tell you that it would be impossible for the two to look anything a like. Unfortunately, the Slingbox is much like a roach motel. Things go in but they don't come out. As far as I can understand, the Slingbox processes the XML from the website and stores it as a "L9999" file within itself. This is a completely different process from using the Slingplayer to upload custom bins into the Slingbox. So, I am unable to figure out if they are stored in the same or separate container with the bin files.

By their very nature, bin files (which are really reformatted device upgrades) must include a device type and setup code. Those concepts are totally irrelevant for learned signals, so it would make no sense to embed those in a learned signal file.

Once I learned that the relative XML files contained UEI Learned Signals, that has been my assumption as well. In fact, that information had lead us to two separate discoveries. One, we no longer need to buy a separate IR widget to learn the codes since it is already built into the Slingbox. If someone was missing a few functions from their remote, then they could send us either the XML file or the IRZ file with the missing buttons. Then we could use IR.exe to decipher the codes and include them in bin updates.

The other discovery was the ability to use functions from many remotes under one profile. This is big first as far as the Sling community is concerned. Since before, we were limited to the bin device upgrades which could only function as one remote.

We know exactly what the format of a 'standard' bin is, and we also know exactly the format of learned signals. There is no similarity.

Exactly. Which is why I'm not trying to "program" learned codes with device upgrades.

[vickyg2003]

Well I'm still confused about what you are trying to do, especially since I don't really understand what a slingbox is, never mind a skin.

I can tell you how a learn is handled in a remote, which might give you some insight into how a slingbox might handle a learn.

Learns are stored in a separate partition of memory.
Learns have a 3 byte header
keycode, device index, length, followed by the learn format that was shown in your file.

The remote walks through the learning area. It seaches for the keycode, device index.

It terminates the search when the next keycode is the terminator which is either 00 or FF depending on the remote.

[eferz]

Well I'm still confused about what you are trying to do, especially since I don't really understand what a slingbox is, never mind a skin.

You know, I've been reading a lot of your posts regarding the Slingbox. And that's the one point you keep bringing up. So, if you'll indulge me then please look at the following link http://support.slingbox.com/go/solo-start. It takes you to a webpage with a quick 3 minute video that shows you exactly what a Slingbox is and does.

If you want, send me a PM and I'll even setup a way for you to play around with my Slingbox. It'll give you an even better understanding. All you would need is the free Slingplayer software, my Slingbox ID, and my guest password.

I can tell you how a learn is handled in a remote, which might give you some insight into how a slingbox might handle a learn.

Learns are stored in a separate partition of memory.
Learns have a 3 byte header
keycode, device index, length, followed by the learn format that was shown in your file.

The remote walks through the learning area. It seaches for the keycode, device index.

It terminates the search when the next keycode is the terminator which is either 00 or FF depending on the remote.

Awesome, thanks for that! I'll keep that information handy if I ever try to upload learned codes to the Slingbox.

[The Robman]

Vicky, a Slingbox is a device that lets you watch your home TV from a remote location on your laptop. Basically, you hook the Slingbox up to a device, such as your SAT receiver or your PVR, and then you hook the Slingbox up to your internet connection. Then, if you have the Slingplayer software installed on your laptop, you use your id and password to make a remote connection to the Slingbox. The Slingbox has an IR blaster cable which it uses to control your device, and it has a UEI chip inside which is where the remote codes, etc come from.

You can load upgrades into the Slingbox in the form of bin files, and RM can create the bin files, which is how JP1 is involved.

[eferz]

Okay. Instead of me trying to upload 16 different files, I decided to use RM and export a bin file for each of the supported device types. Using the settings in the screenshot below, I used the drop down list for each device type to exported each unique bin. Doing so, I then realized that AMP, Audio, Phono all exported with the filename beginning with "AM" also PVR, Dat, Tape, and VCR all exported with "V" as the device code of the filename.

Uploaded with ImageShack.us

I figured that this would help me figure out the binary equivalent which represents "L". However, by doing so, I started to get confused by Rob's description again. Because the results doesn't actually match the definition. Which leads me to question my results.

For example "C", "S", and "N" all shared the same binary combination "0 0 0 1" also "Y", "L", & "R" = "1 0 0 0", and "H" & "D" = "1 0 0 1". Interesting. I figured that the Slingbox had limited device type compatibilities, so RM translated it for you. Even though 4 bits could give you 16 unique binary combinations, there were only 5 unique patterns which were applicable to the Slingbox.

The other oddity was that the setup code was inconsistent despite not changing that field. It also did not match the decimal translations. I was actually expecting to see a hexidecimal value of 01 instead of AF for the last byte. So, I found it even more confusing when I saw that that the setup code of "0001" in RM actually translated into either "1967" or "943" per Rob's definition. Using the table below, I figured the setup code was only unique from bits 1 through 10.

Uploaded with ImageShack.us

My understanding of computer terms leads me to believe a bit is a single digit binary which can either be on (1) or off (0). A nibble is 4 bits, A byte is two nibbles, and chomp is two byes. This is represented in the bottom half of the table above.

Let's say that the following represents the binary for a 2 byte setup code:

abcdefgh ijklmnop

the device type is represented by abcd, which gives you 16 possible device types.

e will become the first byte of the protocol id, so the byte only has two possible values, 01 and 00 (the second byte of the protocol id is the first byte of the device upgrade data).

fghijklmnop form the actual setup code.

Apparently, "e" represents the first byte, except it is a bit not a byte. Since a byte is represented by 8 bits. In my table "e" would be represented as the 12th bit or the green column. So, I wonder if it meant "e" is the first bit of the byte which represents the protocol ID. Which would imply the protocol ID spanned from 5 through 12 and that 12 is the first bit of the protocol ID.

Then the second part completely dumbfounds me, "the second byte of the protocol id is the first byte of the device upgrade data". I'm starting to think it was meant to say that bits 11 & 12 represent Protocol ID, while 1 through 11 represents the setup code, and that they overlap on the 11th bit. However, I'm not entirely sure.

Maybe, the 12th bit represents the byte of the Protocol ID in remote master. Then bits 4 through 11 represents the the second byte of the protocol ID in remote master. So, in this case 00 5A is the protocol ID. If the first byte "00" can only be represented as being on or off then a single digit can represent it, bit 12. Then "5A" is represented by "0101 1010" so it would span bits 4 through 11.

This means the Protocol ID overlays the Setup Code. If that's the case is this done through XOR, NAND, or NOR calculations? And why is there an inconsistency when all I'm doing is altering the device type?

[vickyg2003]

Rob & eferz, in a definition I know what a slingbox is. But that doesn't mean I "know" what a slingbox is. I also knew in theory what a PVR was, but last week I had my first encounter with a PVR, and now I know what a PVR is.

efzera, Have you read this post?
https://www.hifi-remote.com/forums/viewt ... encryption I thought I had pointed it out to you, but I guess that was Alan.

[The Robman]

When you want to see the hex that gets generated based on the device type you select, you should have the JU Slingbox selected as that one isn't encrypted, all the other Slingbox models are encrypted.

When you create an upgrade in RM, the upgrade code is visible in the Output tab. You'll notice that there are two blocks that look something like this...

Upgrade Code 0 = 60 00 (Cable/0000) (RM v1.98beta7)
41 00 01 5E F3 FF
End

Upgrade protocol 0 = 00 41 (S3C80) TiVo (Advanced) (RM v1.98beta7)
43 8D 31 8B 12 CF 44 08 08 01 1A 01 06 01 1A 03
31 D7 42 11 A7 08 B7 08 05 E4 06 05 60 06 46 06
F0 54 C0 06 F6 01 46 46 29 0D 8D 01 49
End

Notice the first byte of the "Upgrade Code" is "41" and notice the protocol id in the 2nd block is "00 41". Also, if you get the "e" bit from the setup code hex (ie, "60 00") you'll see that it's 0. So that single bit becomes the whole first byte of the protocol id (ie, bit 0 becomes byte 00).

Here's another example...

Upgrade Code 0 = 08 00 (Cable/0000) (RM v1.98beta7)
11 00 01 5E F3 FF
End

Upgrade protocol 0 = 01 11 (S3C80) TiVo (Official) (RM v1.98beta7)
43 8D 31 8B 15 CA 5D 08 08 01 21 01 06 01 21 03
31 D4 FD 11 A7 08 B7 08 02 08 E4 05 07 56 07 F0
08 06 60 C0 56 C0 0F 44 C0 07 8D 01 33
End

This time the "e" bit is 1, the first byte of the upgrade is "11" and the protocol id is "01 11", so this time the single bit is value 1 and it becomes the first byte of the protocol id (ie, 01).