RM/RMIR v2.03 available

Post by **mathdon** » Thu Sep 10, 2015 9:28 am

Thanks, Alan. This appears to be due to an error in protocols.ini. Open it with a text editor and find the entry starting

Code: Select all

[RC6-M-20n]
PID=00 20
VariantName=short

Change the DeviceTranslator item to

Code: Select all

DeviceTranslator=BitDoubler(0,3,2) \
                 BitDoubler(1,8,12) \
                 BitDoubler(2,2,36) \
                 Translator(2,1,28,3) Translator(2,1,29,3,comp) \
                 Translator(2,1,30,2) Translator(2,1,31,2,comp) \
                 Translator(3,1,08,0) Translator(3,1,10,0,comp) \
                 Translator(3,1,09,0) Translator(3,1,11,0,comp)

The change is that the line BitDoubler(2,2,36) has been moved from below to above the following two Translator entries. You should find that this resolves the issue.

alanrichey · Post by **alanrichey** » Thu Sep 10, 2015 11:36 am

Thanks Graham, it fixes RC6-M-20n but the MCE protocol (which I know is a derivative of the RC6-M-20n also fails in the same way. But that doesn't have a DeviceTranslator entry ?

And can you explain why there are 3 separate entries for RC6-M-20n (all of which were broken)

Al

Post by **mathdon** » Fri Sep 11, 2015 5:50 am

alanrichey wrote:Thanks Graham, it fixes RC6-M-20n but the MCE protocol (which I know is a derivative of the RC6-M-20n also fails in the same way.

I can't work with statements like this, I need actual files in which the error occurs. Please post pairs of files, .rmdu and .bin, as you did for the previous error. I tried a quick test of taking your previous .rmdu file, changing the protocol to MCE, exporting it as a binary upgrade and then importing it again, and it worked without error as far as I could see.

In checking things out I did, however, find another error in protocols.ini. You should delete the entry for [pid: 012A] as this is actually the HCS08 code for MCE variant 2 which is already elsewhere in the file. I don't think this is the cause of whatever you are seeing, but do this deletion to make sure.

And can you explain why there are 3 separate entries for RC6-M-20n (all of which were broken)

I don't know about this specific case, but they have different variant names, which usually means that UEI has written more than one executor for a protocol and they have different relationships between device parameters (human readable) and fixed data (the processor-readable equivalent). If the other entries are still broken, then as before, please post files.

alanrichey · Post by **alanrichey** » Fri Sep 11, 2015 7:36 am

Hi Graham

Sorry about that, I thought any MCE based RMDU file would show that behaviour. RMDU and BIN file now at http://www.hifi-remote.com/forums/dload ... e_id=13553.

S2010_PL.BIN was exported from the RMDU file, which uses MCE and Device 38 and OEM2 (which I assume is equivalent to sub-device) of 72. Importing it back gives the same results as we had before.

The other copies of RC6-M-20n had the same errors so I simply corrected them. I assume you will fix the official release ?

And I see the different variant names for the 3 examples ("", "2" & "short"), but when I select a protocol in RM I only get a single choice. How does it know which one to use ? or doesn't it matter ?

Later: just gone in to delete 012A, but there are 2 of them. Which one is wrong ?

Thanks

Al

Post by **mathdon** » Fri Sep 11, 2015 9:31 am

You are making me wonder if we are looking at the same version of protocols.ini. In the version in RMIR v2.03 build 8, there is only one protocol with the heading [pid: 01 2A]. There are others with PID=01 2A but not as the heading in square brackets. It is the one headed [pid: 01 2A] that should be deleted.

There are three protocols headed [RC6-M-20n] but only one of them has the error I described. Of the other two, one does not have any BitDoubler entry and the other does not have a clash between a BitDoubler and a Translator entry (i.e. same first digit, in which case the BitDoubler entry must be before the Translator ones). I will see that the one with the error is corrected in the next release.

The assumption of RM is that all protocols with the same name send the same signals, so it shows the first that supports the processor of the remote. It is only with built-in protocols that the version is critical, as RM must select the one built in to the remote, which it does from the RDF. However, in build 8 only one of the three versions of [RC6-M-20n] has S3C80 code, so that is one shown.

I will look into your new files, but have not yet had time.

alanrichey · Post by **alanrichey** » Fri Sep 11, 2015 10:28 am

Sorry, just showing my ignorance of the nuts and bolts of the system. I hadn't differentiated between PID=01 2A (The MCE Protocol) and [pid: 01 2A] (The standalone one). Happy now.

Later: Just seen that removing that PID helps a bit. The MCE now imports as RC6-6-32 with a huge sub-device. I assume these are actually the same ?

Post by **mathdon** » Fri Sep 11, 2015 10:51 am

I see that the .bin file you have posted shows up as pid: 01 2A with 8 device parameters, but if I export your .rmdu file as a .bin myself and re-import it, it shows as RC-6-6-32. This appears to be synonymous with MCE, the functions look the same as in the original .rmdu file. So I think that the corrections to protocols.ini that I suggested have affected the export process and it now appears to work OK.

If you still see a problem, please post again.

Edit: I hadn't seen your latest post when I posted this, but we seem to be in agreement.

Post by **mathdon** » Fri Sep 11, 2015 11:01 am

alanrichie wrote:The MCE now imports as RC6-6-32 with a huge sub-device. I assume these are actually the same ?

I can confirm that they are the same, as the fixed bytes and protocol executor are both the same, which is all that is required for them to have identical behaviour.

alanrichey · Post by **alanrichey** » Fri Sep 11, 2015 11:21 am

Good stuff. Thanks for helping me out.

Post by **ElizabethD** » Sun Sep 27, 2015 8:53 pm

This .IR file will not load into my RMIR v2.03 build 1. Opens fine in IR.
http://www.hifi-remote.com/forums/dload ... e_id=13529
Task error, Error loading file ... The filename has ext4 in it, but it's for 1994 extender v5.

Calculating default fixed data and command lengths
Calculated: Fixed data length = 2, Command length = 1
Using "pid: 01 5E" (01 5E)
Translator.in() index=0 missing parameter value
Translator.in() index=1 missing parameter value
Translator.in() index=2 missing parameter value
Translator.in() index=3 missing parameter value
Error setting new RemoteConfiguration: 41
java.util.concurrent.ExecutionException: java.lang.ArrayIndexOutOfBoundsException: 41

I don't see pid 015e in this file. Don't know if that's relevant.

Sorry about that RMIR build 1, I'll upgrade soon

Post by **mathdon** » Mon Sep 28, 2015 5:58 am

ElizabethD wrote:This .IR file will not load into my RMIR v2.03 build 1. Opens fine in IR.

The problem lies with the file, not RMIR. If you open it in IR, look at the Devices tab and select VCR/DVD 0573, you will see that the PID is 15E. This protocol is neither built-in nor an upgrade on the Protocols tab. IR doesn't cross-check between Devices and Protocols, but RMIR does. So IR will load it but RMIR will not. I suspect that if you upload this to the remote, the AUX2 device will not work as this is the one that uses this device upgrade.

There is a protocol in protocols.ini with PID=015E, but it is not the missing one. It is a very peculiar one, with 6 fixed bytes and 4 variable bytes, but if you look at the Devices tab in IR, you will see that the VCR/DVD 0573 device has 2 fixed bytes and 1 variable byte. So it looks as if you are missing a protocol upgrade from some other source. The RMIR loading fails because it takes the protocols.ini entry to be the missing protocol and so tries to interpret the device upgrade as if it has 6 fixed and 4 variable bytes. It crashes as the upgrade is not long enough to be interpreted in this way, its end is reached prematurely.

Hope this makes sense.

Post by **ElizabethD** » Mon Sep 28, 2015 9:43 pm

Explains perfectly well. Thank you.
It's actually not my file, it's Rob's. And he has issued another version anyway at which I was looking, and RMIR has no issue with that one.

Post by **The Robman** » Tue Sep 29, 2015 6:59 am

I thought that VCR/0573 code sounded familiar, I took a look at that file, I had accidentally checked the "Protocol > FF" box.

Just for fun, I tried loading my current file into RMIR and it abended too, but I figured out why. I had added an entry to the [SpecialProtocols] section of the RDF so that my Replay Select protocol would be recognized as a special protocol (I added Replay_Sel=01FA) and this worked in IR.exe but caused RMIR to choke. When I deleted the entry from the RDF, the file opened fine in RMIR.

Here's the file that uses the Replay Select special protocol:
http://www.hifi-remote.com/forums/dload ... e_id=13577

Post by **mathdon** » Thu Nov 19, 2015 10:22 am

I have now posted build 10 of RMIR v2.03. This new build is available both as a complete installation file and as an upgrade to any of the earlier builds, both from the link just given. Note that build 9 was not publicly released, so this is the first update since build 8.

The main changes from build 8 are:

All bugs notified since build 8 have been fixed
For XSight Touch, Nevo and similar remotes, the Buttons panel of the Device Upgrade Editor now allows you to select an icon instead of a text alias for functions from a different device
The Option/Font Size Adjustment setting in RM is now preserved between instances
An RDF for Nevo C3 has been added and many other RDFs have minor updates
Several entries in protocols.ini have had minor corrections

If I have missed any bugs, please post a note in this thread about them.

Post by **The Robman** » Thu Nov 19, 2015 4:30 pm

Thanks Graham.

Could you also update this copy please, as SF is blocked for me at work:
http://www.hifi-remote.com/forums/dload ... e_id=13495