RM import from KM two device Sony

rickety · Post by **rickety** » Mon Sep 22, 2003 8:17 pm

When using RM .66 and importing a KM upgrade, the results did not match the original KM output. It was a two-device-code upgrade but the second device code seemed to get lost in the conversion.

I noticed that the same thing happened when using the KM option to output a .km file earlier.

Just fyi, it was easily overcome, but I thought I'd mention it as I notice that more and more folks seem to be looking to use RM and if they pick up an existing two-device-code upgrade it may not work properly.

Congratulations to those who have crafted RM.

Nils_Ekberg · Post by **Nils_Ekberg** » Tue Sep 23, 2003 7:58 am

The import function of KeyMapMaster files into RM is a "work in progress" and works reasonably well with single byte protocols and kind of hit and miss with multi byte and combo protocols. Greg is working on improving it in between other functions he is adding.

If you can upload the KM upgrade file to the diagnostic area of jp1 Yahoo I can take a look at the import and pass on to Greg where it is breaking down.

Nils_Ekberg · Post by **Nils_Ekberg** » Tue Sep 23, 2003 9:03 am

I also noticed that since KM works off of one choice for the RDF/remote (the unextended version) and only records the remote "generic" name in the .txt file when it is imported into RM a choice of RDF's is offered of all the RDF's that match the remote name. This is because RM allows the use of all RDF's for building upgrades where KM has a built in table instead of using the RDF (I think).

I think this is only a problem if a version of the RDF is selected during the import that was not what it was built with and has some differences but I am not sure so I will do some testing.

rickety · Post by **rickety** » Tue Sep 23, 2003 7:30 pm

I have posted the KM file to Diagnosis folder. It's called ....

1000-Sony TV Scan-split buttons (rpl).txt

hope this helps

Nils_Ekberg · Post by **Nils_Ekberg** » Wed Sep 24, 2003 6:59 am

It looks like RM is picking up everything correctly with the exception of the second device. This obviously throws everything off including the fixed data.

The Original KM file entry is Devices:,Sony 12/15,119,164,,,, so it looks like RM is not parsing the data correctly. Greg or John will need to look at that piece of the code.

gfb107 · Post by **gfb107** » Thu Sep 25, 2003 4:37 pm

Taking a look at it now....

Well, there's a couple of things going on here:

1. KM and RM don't use the same protocol (aka device) parameters for the Sony 12/15 protocol. In RM, the second parameter is a boolean, which when assigned a non-zero value is treated as TRUE. The third RM parameter is the second device type, which is KM's second parameter. I can probably add code to skip over boolean parameters, since those are new to RM, but there will always be cases where changes like this will cause import problems.

2. There's some other bug causing Rm to think there are 2 other functions defined: "Split" and "Pic Mode", assigned to Display and Swap, respectively. I'll have to look at that more closely.

gfb107 · Post by **gfb107** » Thu Sep 25, 2003 5:41 pm

Skipping over the boolean parms during import fixed this problem. It won't handle every case (where the use-device-15 flag is encoded in the device number, for example), but it's better than it was.

Looks like the KM device upgrade was created with an older version of KM ( version 6.00 beta something). When I loaded and resaved it using KM v 7.45, the problems with the extra functions getting imported disappeared. I'm not sure I'll be putting any more effort into resolving that one.

rickety · Post by **rickety** » Thu Sep 25, 2003 8:11 pm

In fact the "upgrade" was to define those two functions for keymoves into other devices (my remote does not use the upgrade directly for any device). So those two functions are the ones defined in that upgrade and the assignments to keys is immaterial. In fact only one (DRC mode) shows as assigned (to Move key) in KM 7.53.

It seemed interesting to me that both the KM save as "km" option, and the rm import both "missed" the second device code. Glad if you've been able to solve that.

gfb107 · Post by **gfb107** » Fri Sep 26, 2003 9:16 am

John,

It occured to me that this could be handled using ImportTranslators for each protocol, similar to the DeviceTranslators and CommandTranslators we have now. The default translators could just do a positional copy, with special case ones written for cases like this.

Not sure it is worth the effort, though.