JP1 Remotes

The only change from 4.00 is that users can now specify the directory where the RDF files are stored. This provides better interoperability with programs (such as RM) that also use RDFs.

Nice work, Mark!

FYI... not a big deal, but Help, About still shows as 4.00.

Mark Pierson wrote:Help, About still shows as 4.00.

Oops! Thanks for the heads-up. I just corrected that and refreshed the zip. (The version number is a bit more important now because it triggers the warning to download the most current RDFs. Not a big deal at this point because (to the best of my knowledge) there have been no RDF changes since I released 4.00. Still, the version numbers should be correct.

Just a curious question that I came across during the mods to the Extender loader protocol for the 9960.

What is the significance to the sequence of devices in the [DeviceTypes] section of the RDF. Most RDF's have them in order, ie: device 0 first then 1 then 2 etc. Some however have them in random order.

I know that the [DeviceTypes] and [DeviceTypesAliases] need to be in the same order and the order is what shows up in IR etc. but is there anything else that this effects.

The devices need to be listed in [DeviceTypes] in the order of their dev index (0-based) to be enumerated correctly. I don't understand what you mean by random order. Don't forget that there's no real consitency from one model to another (I can only assume you're referring to CBL, TV, VCR..., as opposed to TV, VCR, CBL...)

Mark Pierson wrote:. I don't understand what you mean by random order. Don't forget that there's no real consitency from one model to another (I can only assume you're referring to CBL, TV, VCR..., as opposed to TV, VCR, CBL...)

No, I am actually talking about the device number order.

• Here is the entry from the 6_806_80 (URC-881x_801x_601x).rdf
  6_806_80 (URC-881x_801x_601x).rdf
  [DeviceTypes]
  TV = 0
  VCR/DVD = 1
  Audio = 2
  CBL/SAT = 3
  
  Here is the entry from the NAK0NAK0 (URC-9960 One For All Kameleon).rdf
  [DeviceTypes]
  SAT/CBL = 1
  TV = 0
  VCR = 3
  DVD = 2
  CD = 5
  AUD = 4

This actually made the Extender loader protocol fail since IR actually treated SAT/CBL was device 0. Once I reordered them it worked. (That's a qualified "worked" since the extender has other problems I am working on.)

Those aren't the device numbers... they indicate which button map is used.

Mark Pierson wrote:Those aren't the device numbers... they indicate which button map is used.

Yup, I knew that, so the order of the buttons decides if it is 0 or 1 etc. That's why reordering it worked. Don't know what I was thinking...

Remember, the RDFSpec3.doc file has all the particulars about the RDF entries.

Mark Pierson wrote:Remember, the RDFSpec3.doc file has all the particulars about the RDF entries.

Yup, I knew that but it just didn't answer the order requirements and how it is decided.

I guess what I am asking is how important is the order TV, VCR, etc. and does it have to match a remote internal order that I am missing.

Yes... the order IS important. Entry 1 is device 0, 2 is 1, 3 is 2, etc. It must match EXACTLY what the remote uses or you'll really muddy up the waters!

BTW, I think device 0 is always the current device when the remote resets. You'll probably need to know that for activation purposes.

The RDF spec seems a little unclear to me also about this, but:is equivalent to(but it isn't real clear about what would happen with something like this)So, it you want to list the buttons out of order, then you must supply the second value.

mr_d_p_gumby wrote:So, it you want to list the buttons out of order, then you must supply the second value.

I'm not positive, but I think IR enumerates the list in the order it appears to determine the dev index. That 2nd value, referred to as Type in the spec, I believe has another purpose in life. I don't think you can override the raw enumeration with it. Also, there's the stuff about needing TypeAddr in the [DeviceButtons]... or does IR enumerate THAT section? Now I'm confused!!!