View previous topic :: View next topic |
Author |
Message |
rickety
Joined: 03 Aug 2003 Posts: 101
|
Posted: Mon Sep 22, 2003 9:17 pm Post subject: RM import from KM two device Sony |
|
|
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. |
|
Back to top |
|
|
Nils_Ekberg Expert
Joined: 02 Aug 2003 Posts: 1689 Location: Near Albany, NY |
Posted: Tue Sep 23, 2003 8:58 am Post subject: |
|
|
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
Files Section
Diagnosis File Section |
|
Back to top |
|
|
Nils_Ekberg Expert
Joined: 02 Aug 2003 Posts: 1689 Location: Near Albany, NY |
Posted: Tue Sep 23, 2003 10:03 am Post subject: |
|
|
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. _________________ Nils
Files Section
Diagnosis File Section |
|
Back to top |
|
|
rickety
Joined: 03 Aug 2003 Posts: 101
|
Posted: Tue Sep 23, 2003 8:30 pm Post subject: |
|
|
I have posted the KM file to Diagnosis folder. It's called ....
1000-Sony TV Scan-split buttons (rpl).txt
hope this helps |
|
Back to top |
|
|
Nils_Ekberg Expert
Joined: 02 Aug 2003 Posts: 1689 Location: Near Albany, NY |
Posted: Wed Sep 24, 2003 7:59 am Post subject: |
|
|
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. _________________ Nils
Files Section
Diagnosis File Section |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Thu Sep 25, 2003 5:37 pm Post subject: |
|
|
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. _________________ -- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Thu Sep 25, 2003 6:41 pm Post subject: |
|
|
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. _________________ -- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
Back to top |
|
|
rickety
Joined: 03 Aug 2003 Posts: 101
|
Posted: Thu Sep 25, 2003 9:11 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Fri Sep 26, 2003 10:16 am Post subject: |
|
|
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. _________________ -- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
Back to top |
|
|
|