RM/RMIR v2.03 available

[DaCoynul]

Using an Atlas 1056B01 JP1.3 remote I am getting "malformed learned signal" "hex learned signal too short to unpack" errors when I try to add learned signals (cut and paste pronto hex) in any RMIR build under both Arch linux with kernel 4.5 and Xubuntu with kernel 4.4. I get the same error on Windows 7 running in a VM on the Arch box. I have tried Java runtime 8, 7, and 6 with the same results. The same pronto hex cut and pasted into IR 8.03 in the Windows VM works fine. Any idea what could be going wrong here?

Jon

[mathdon]

When you use IR.exe you will have seen that you can select between UEI Learned and Pronto Hex. RMIR only supports UEI Learned, so any attempt to import Pronto Hex will fail.

There are tools that will convert Pronto Hex to UEI Learned if you want to import with RMIR. IRScrutinizer is one with powerful import/export facilities. There are no plans to build Pronto Hex support into RMIR. It is there in IR.exe as that pre-dates the availability of independent conversion tools.

[The Robman]

Would it be hard to add support for that to RMIR Graham? I use that feature in IR.exe a lot.

[mathdon]

Would it be hard to add support for that to RMIR Graham? I use that feature in IR.exe a lot.

There are two possibilities, neither of which are straightforward. One would involve adding Java support to ExchangeIR.dll, the other would be to link in some fashion to the conversion routines in Barf's IRScrutinizer. I really don't want another library that has to be compiled separately for each of Windows, Linux and Mac OS X so would be very reluctant to follow the first route. I have no knowledge of IRScrutinizer, I've never even used it, so I can't follow the second route. However, I think that Barf has had thoughts of linking RMIR and IRScrutinizer in some way and I would have no objection to him linking conversion routines into RMIR if he is interested in doing so.

[Barf]

Would it be hard to add support for that to RMIR Graham? I use that feature in IR.exe a lot.

There are two possibilities, neither of which are straightforward. One would involve adding Java support to ExchangeIR.dll,

Let me remind you that I ported ExchangeIR to Jave, see this posting. It is in our SVN.

... However, I think that Barf has had thoughts of linking RMIR and IRScrutinizer in some way and I would have no objection to him linking conversion routines into RMIR if he is interested in doing so.

Well, I have been up to two projects:

1. getting raw ("pronto hex") data into RM, and
2. getting raw data out of RM.

For 1., see the first attempt. Since then, I have given up that route, instead relying on RM's ability to translate OBC, and, essentially, shove the task of mapping the protocols to executors to the user by generating a "dumb" RM export, see this, the last few postings.

For 2. see this thread, in particular the end.

As a general principle, I am positive to integrating RM and IrScrutinizer; they are both Java and share the same license, and a lot of other things...

[mathdon]

Let me remind you that I ported ExchangeIR to Java, see this posting. It is in our SVN.

I thought you had not ported the Pronto/UEI conversion part of ExchangeIR, which is the part relevant to Rob's request, as you didn't like the way I had done it.

[Barf]

@mathdon:
Sorry for my imprecise statement. Yes it the Pronto encoding/decoding was not in my conversion, the reason being essentially that I did not need it myself. The reason that it was not added subsequently was that no-one asked for it. Possibly still not too late...

Having said that, writing Pronto hex decoding/encoding routines is (as opposed to UEI learned) is a fairly trivial task for someone like us. This is the code in IrpMaster/IrScrutinizer, possibly better to use is this version, which consists of static functions only. Help yourself, or ask for help.

A showstopper this is not.

[mathdon]

Since Rob wants it and Barf is encouraging me to do it, I will look into it. I don't have much time at present, though, so I am not sure when it will be. It is unlikely to be in the first public build of RMIR v2.04, as I hope that is now imminent.

[The Robman]

No rush on my part.

[Knuckx]

I'm using 2.04build2 for a JP1.4N remote, but when trying to download from a URC7781 (JP1.2), I get the 'cannot download' message. rmaster.err from one download attempt. This remote works fine with 2.03build14.

[mathdon]

Sorry about that, Knuckx. Please try the revised jar file here in RMIR v2.04 build 4.

[Knuckx]

Yep, that fixed it, both opening and downloading the files for the URC7781 works again. Just tried DLing all the remotes easily available from my desk: a JP1.2, 2 different JP1.4 and a JP1.4N all appear to work.

Thanks.

[mathdon]

Could a Mac user please look at this thread. It concerns a user of RMIR under Mac OS X who can upload and download without problem with JP2 remotes but not with JP1.3 remotes. I have no experience with Macs so it would be nice if a Mac user could shed any light on the matter. I feel sure we have Mac users who use RMIR with JP1.3 remotes, so it seems strange to me.

[andgarden]

Thank you for that mathdon. As the Mac user from the linked thread, I am happy to help troubleshoot if someone with more technical knowledge can give guidance.

[tranx]

I have just installed RMIR on a new PC with Windows 10 and found that the displayed lines of text are compressed vertically, so much that it's hard to read. Text on a single line, or from side to side, looks normal. (Java 8, update 91)

Native screen resolution is 3840 x 2160 but when this is changed to 1920 x1080, (with which and Windows 7 RMIR was working fine before on the other PC) it makes no difference, which I suppose is not surprising.

What have I done wrong or is there something missing in my new Win 10 installation please?

PS
Not sure of the right terminology but it seems that 'static text' is ok, but it is just the items in the 'listboxes' which are not displayed correctly.