New RDF and Maps/Image Release 1.31

[mdavej]

Why can't RM be changed so it doesn't need a linefeed?

And why is there any relationship at all between the number of of device types and the number of device buttons? That doesn't make any sense.

[vickyg2003]

Chris, I've put together a complete list. I haven't refined it to be an "error" report, because I really don't understand the data.


https://www.hifi-remote.com/forums/dload ... le_id=8942

Look at the kind of errors there are and see if you want me to only show the ones that have more buttons than device types, or do you want to look at all the stuff.

It would appear that I'm not the only one that doesn't understand the DevictTypes section.


Oh and speaking of sections do these weird sections cause any problems for IR or RM or RMIR?

[SpecialProtocols+]
[Settings2]
[DeviceButtons+]
[Checksums]0
[Checksums2]

[The Robman]

We typically add a number to the end of a section name as a way of commenting it out, so those really should still be in production RDFs.

[mr_d_p_gumby]

And why is there any relationship at all between the number of of device types and the number of device buttons? That doesn't make any sense.

Most people seem to grasp that the [DeviceTypes] section defines the device types (internal device #, keymap used, etc.), but a secondary purpose is to define the native device type of each device button. Could this have been done another way? Sure, but it's been this way since the dark ages of JP1, and we've tried our best to keep the RDF files as backward compatible as possible.

[mr_d_p_gumby]

Oh and speaking of sections do these weird sections cause any problems for IR or RM or RMIR?

The sections ending with a '+' were added by Graham for the RDF v4 spec. They are ignored by programs that don't know about RDF v4 , but IR v8 (& now RMIR) will use them in preference to the sections of the same name without the '+' at the end. So, both are valid as far as your checker program is concerned.

[mathdon]

Why can't RM be changed so it doesn't need a linefeed?.

In some sections, each entry is a single line but in others the data is allowed to run on from one line to another without any special continuation character. These latter sections have to end with a blank line, otherwise the following section is taken as invalid data in the preceding section. Since it also aids readability, I hardly think it is much to ask to put blank lines between sections.

And why is there any relationship at all between the number of of device types and the number of device buttons? That doesn't make any sense.

Actually there is no such relationship, which is why the RDFs currently work. There is no problem with their being either fewer or more device types than device buttons. But each device button has a default device type, and in the RDF Spec the default device types are specified by matching the items in order in these two sections. If there are more buttons than types then the last type is used for all remaining buttons. If there are more types than buttons then the excess types are not used as defaults for any buttons.

Incidentally, the RDF Spec is wrong when it says that the order of entries in the [DeviceButtons] section is not important. It is very important. The order determines the index used in key moves etc to refer to that button (the topmost button having index 0).

[vickyg2003]

And why is there any relationship at all between the number of of device types and the number of device buttons? That doesn't make any sense.

Actually there is no such relationship, which is why the RDFs currently work. There is no problem with their being either fewer or more device types than device buttons. But each device button has a default device type, and in the RDF Spec the default device types are specified by matching the items in order in these two sections. If there are more buttons than types then the last type is used for all remaining buttons. If there are more types than buttons then the excess types are not used as defaults for any buttons.

The problem with the RDF's not following the rules is that

Is that if you do a file->new to start your image, the wrong device type is assigned to the button. That's akin to doing 992's on all your buttons. Now if you programmed something into a remote with cable, it can be very difficult to tell if you need to go back to manual use for any reason.

When you try to do the setup for a DVD you might be getting the code for a TV because the device type of the button is incorrect. Or you might get a long blink when the code doesn't exist in the current mode.

So it is important to correct these for future users, incase anybody needs to do a file->new so that they get the native setup codes.

[mathdon]

So it is important to correct these for future users, incase anybody needs to do a file->new so that they get the native setup codes.

Absolutely. I was just answering mdavej's questions, not trying to say it wasn't necessary to sort it out.

[vickyg2003]

So it is important to correct these for future users, incase anybody needs to do a file->new so that they get the native setup codes.

Absolutely. I was just answering mdavej's questions, not trying to say it wasn't necessary to sort it out.

Yes, I was trying to clarify that for MdaveJ.

[mdavej]

Thanks to all for the clarification. So all we need to do is add more entries to device types and perhaps rearrange a little so we have a one-to-one match with device buttons, and in the right order.

[vickyg2003]

Thanks to all for the clarification. So all we need to do is add more entries to device types and perhaps rearrange a little so we have a one-to-one match with device buttons, and in the right order.

Yes but it is complicated. There are all those rules that apply. Look at Page 30 of the RDF4Specs and look at the file that I posted that shows all the settings as they now are in the RDF's

First of all before you start rearranging you need to figure out the setup code assignment that goes with each device type entry, and type them in without making a mistake, and then rearrange them according to the button order.

Its above my abilities.

[ElizabethD]

In these RDFs
PVR0PVx1 (URC-6131(Old)_6131nwB00 PVR Remote Extender1 2K).rdf
and
PVR01Kx1 (URC-6131(Old)_6131nwB00 PVR Remote Extender1 1K).rdf
a change needs to be made because DSM protocol is bundled within the extender.
The change is from "DSM=01FC" to what you see below.
[SpecialProtocols]
DSM=TV/1103:-01FC
LDKP=01F9
Multiplex=01FE
Pause=01FB
ToadTog=0181
This change is needed so that IR and RMIR permit use of DSM even when we don't add the few bytes for the DSM device TV/1103.

[vickyg2003]

Chris, is the report format satisfactory? If so I'll add it to the menu and wrap it into the by-RDF report.

There are a few errors where the #buttons and #devtypes match, but the implied count leads to a setup type that is outside the range that the remote allows.

[mr_d_p_gumby]

Yes but it is complicated. There are all those rules that apply. Look at Page 30 of the RDF4Specs and look at the file that I posted that shows all the settings as they now are in the RDF's.
...
Its above my abilities.

Maybe an example would help. In your report file, for the URC-8820, you list:

Code: Select all

10631063 (URC-6820_8820_10820).rdf                                         
[DEVBUTTONS]         [DEVTYPES]   [MAP, DEVTYPE NUMBER]               

CBL                   SAT/CBL                    0                            
SAT                   TV                         1                            
TV                    VCR/DVD                    2                            
VCR                   CD                         3                            
CD                    PVR                        2                            
DVD                   AUD                        3                            
PVR                                                                           
AUD                                                                           
AUX1                                                                          
AUX2                                                                          
Remote contains    6 setup code types.

This should be fixed (I picked this one as an example because I know you are familiar with this remote). Below is the corrected RDF entry, with some extra comments to help in interpreting the entries (comments to be omitted from the actual RDF).

Code: Select all

SAT/CBL = 0,0    CBL/SAT Uses keymap 0 & device type 0; CBL  button is SAT/CBL type
SAT/CBL = 0,0    CBL/SAT Uses keymap 0 & device type 0; SAT  button is SAT/CBL type
TV      = 1,1    TV      uses keymap 1 & device type 1; TV   button is TV      type
VCR/DVD = 2,2    VCR/DVD uses keymap 2 & device type 2; VCR  button is VCR/DVD type
CD      = 3,3    CD      uses keymap 3 & device type 3; CD   button is CD      type
VCR/DVD = 2,2    VCR/DVD uses keymap 2 & device type 2; DVD  button is VCR/DVD type
PVR     = 2,4    PVR     uses keymap 2 & device type 4; PVR  button is PVR     type
AUD     = 2,5    AUD     uses keymap 2 & device type 5; AUD  button is AUD     type
AUD     = 2,5    AUD     uses keymap 2 & device type 5; AUX1 button is AUD     type
SAT/CBL = 0,0    SAT/CBL uses keymap 0 & device type 0; AUX2 button is SAT/CBL type

Using the 'complicated' rules, the entry can be done this way:

Code: Select all

SAT/CBL = 0
SAT/CBL = 0,0
TV      = 1
VCR/DVD = 2
CD      = 3
VCR/DVD = 2,2
PVR     = 2,4
AUD     = 2,5
AUD     = 2,5
SAT/CBL = 0,0

Note that both sets of entries will produce identical results. Also, when a device type is repeated in the list, note that it always has the same parameter result. I'm not sure which one IR (or RMIR) actually uses as the device type definintion (first, last?), but it will not matter if they are all the same.

[vickyg2003]

Using the 'complicated' rules, the entry can be done this way:

Code: Select all

SAT/CBL = 0
SAT/CBL = 0,0
TV      = 1
VCR/DVD = 2
CD      = 3
VCR/DVD = 2,2
PVR     = 2,4
AUD     = 2,5
AUD     = 2,5
SAT/CBL = 0,0

Note that both sets of entries will produce identical results. Also, when a device type is repeated in the list, note that it always has the same parameter result. I'm not sure which one IR (or RMIR) actually uses as the device type definintion (first, last?), but it will not matter if they are all the same.

Yep, that's the one that's complicated.

I find this kind completely uncomprehendable, although sitting here staring at it, do I start counting from 0, and then skip counting for anything that has a comma in it?

If so then I could also count the numbers then I could point the errors where there are more setup types than = signs in the device setups section. As you note, I reported there were 6 device types in the remote by counting those = signs.

Maybe an example would help. This should be fixed (I picked this one as an example because I know you are familiar with this remote). Below is the corrected RDF entry, with some extra comments to help in interpreting the entries (comments to be omitted from the actual RDF)

Yep, that is the one that I saw and reported.

You'll note that the report lists the buttons and the device types side by side, because then its more obvious to me when the buttons and device types don't line up.

I can also filled in an implied setup type if I understand the counting.

I can't automatically fix this obviously, but it sure would be nice to be able to flag errors.