DecodeIR 2.44

Barf · Post by **Barf** » Thu Nov 01, 2012 4:46 am

3FG wrote:The newly posted DecodeIR 2.44 v5 decodes all combinations of Humax 4Phase signals with no false decodes. It tightens up the decoding requirements for Nokia12 and Sony8 in order to avoid these false decodes.

I have tested, thus verified this statement. Even the need to call decode() an extra time has been fixed. Congratulations!

... I've decided to disable the Async decoder. We have dozens of posts describing false Async decodes, and none (I even checked learns in the Yahoo file section) that are legitimate decodes.

This is probably a wise, pragmatic, decision.

I have uploaded current versions of the Linux libraries. Really hoping someone will upload a windows 64-bit version.

3FG · Post by **3FG** » Thu Nov 01, 2012 9:53 am

Thanks for testing. I haven't done anything which was intended to deal with needing to call decode() twice. DecodeIR uses somewhat complicated logic to handle protocols with start and/or end frames, and the need to call twice may result if a two part IR signal is recognized for the first part but not for the second.

Don't shoot the messenger, but regarding 64 bit Windows, the current recommendation from Oracle is: "we recommend using the default 32-bit browser and downloading 32-bit Java". Apparently the 64 bit version of Internet Explorer and some other browsers work poorly with 64 bit Java.

I ran across this because I checked DecodeIR at work on a 64 bit OS and processor, and it worked fine because the computer was set up to use 32 bit Java. So I asked why 32 bit Java and got an earful! 64 bit Java (I'm told) doesn't handle updates to new versions correctly either. I was also told that it increases the memory needed by the process and runs more slowly.

Of course it will be nice if someone (I don't have the capability) can compile a 64 bit version of the dll, but maybe using 32 bit Java is something of a universal workaround at the present time.

Barf · Post by **Barf** » Sat Nov 03, 2012 2:43 am

3FG wrote:Thanks for testing. I haven't done anything which was intended to deal with needing to call decode() twice. DecodeIR uses somewhat complicated logic to handle protocols with start and/or end frames, and the need to call twice may result if a two part IR signal is recognized for the first part but not for the second.

Some of the try*-functions set an internal flag (function local, "static") and expect to reset it in a subsequent call, if successful. So, what happens in the subsequent call does not happen, or is not successful? The internal flag remains in a non-virgin state. This holds even if the decoder starts working on a new signal. There is no way to reset the internal memory, except for the successful subsequent call. The function initDecoder() (from Java) does not do what the name suggests, because of this local memory. Also calling the "constructor" leaves that state alone, and the "newly constructed object" has the same state as the "old".

This is not dangers I make up: in the course of the latest development, as reported in this thread, erroneous behavior came and went again, without being explicitly addressed. (Please take what I am saying as constructive criticism, not bashing.)

Don't shoot the messenger, but regarding 64 bit Windows, the current recommendation from Oracle is: "we recommend using the default 32-bit browser and downloading 32-bit Java". Apparently the 64 bit version of Internet Explorer and some other browsers work poorly with 64 bit Java.

They say that they recommend 32 bit browsing, and in that context 32-bit Java. At least in that note, I cannot find any recommendation against 64 bit Java for applications. I installed IrMaster on 64 bit XP/64 bit Java, and everything seemed to run fine, except DecodeIR.

Moreover, DecodeIR is not a Java issue (only).

Has someone succeed compiling DecodeIR for Windows with mingw (32 or 64 bit?)

but maybe using 32 bit Java is something of a universal workaround at the present time.

yesss..... but for the upcoming new release of IrMaster/IrpMaster I would hate to write "if using 64 bit JVM, everything will work fine except DecodeIR".

MikeT · Post by **MikeT** » Mon Nov 12, 2012 5:30 am

Barf wrote:Has someone succeed compiling DecodeIR for Windows with mingw (32 or 64 bit?)

I've compiled DecodeIR for MacOS 32 and 64 bit. Today 95% of the Intel Mac software are 64 bit applications. There is no current 32 bit version of Java for MacOS, so DecodeIR is always used as 64 bit lib on MacOS.

Are there any unit test cases for DecodeIR that I can run? I just used some learned keys to see if it is working at all, but I don't know if the result of all of them is correct.

Michael

Barf · Post by **Barf** » Mon Nov 12, 2012 2:18 pm

What a coincidence! I was fooling around with my Mac Mini (just upgraded from Snow Leopard to Mountain Lion), succeeded to get everything compiled and running, preparing to upload the shared libs, and you just did it an hour or so earlier!! Using the XCode I downloaded from Apple (containing a really ancient gcc from 2007 if I recall it correctly), I had different compilation issues than you: your 1. and 2. no problem; however, the abs function for float and double argument did not resolve uniquely, so I replace the calls by the (standard C functions) fabs and fabsf.

Furthermore, I noticed that with Snow Leopard the Java system property "os.arch" (System.getProperty("os.arch")) delivers "X64_64" (first X capitalized) while Mountain Lion returns "x86_64" (small "x"). I noted that the previous decodeIR-distribution contains the "X86_64" while yours say "x84_64". I smell potential for trouble.

MikeT wrote: Are there any unit test cases for DecodeIR that I can run? I just used some learned keys to see if it is working at all, but I don't know if the result of all of them is correct.l

You can use IrpMaster to test DEcodeIR against whole ranges of input parameters, generated by IrpMaster. Try, e.g.

Code: Select all

$ irpmaster --decodeir  rc5x   \* 0 0

(Unix-like shell assumed). You can also use IrMaster interactively to interface to DecodeIR interactively with GUI (cut-n-paste).

MikeT · Post by **MikeT** » Tue Nov 13, 2012 2:25 pm

Barf wrote:Furthermore, I noticed that with Snow Leopard the Java system property "os.arch" (System.getProperty("os.arch")) delivers "X64_64" (first X capitalized) while Mountain Lion returns "x86_64" (small "x"). I noted that the previous decodeIR-distribution contains the "X86_64" while yours say "x84_64". I smell potential for trouble.

When you look at the distributions of RemoteMaster V2.01, V2.02Beta, jp12serial 0.18 and DecodeIRV2.41v2, all use the same directory name "Mac OS X-x86_64".
The file "decodeir-2.41-source\Mac OS X notes.txt" refers to the platform "x86_64".
The gcc -arch switch uses the parameter "x86_64".
The environment variable HOSTTYPE is set to "x86_64" on my machine.

I really don't know where "X64_64" or "X86_64" with an uppercase X should come from. Also google has only very few hits with the uppercase X.

Which java distribution (Apple or Oracle) and which version are you using?
"java -version" says on my machine:
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909)
Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode)

This is the current version Java 7, update 9 from Oracle.

I would stay with the directory name "Mac OS X-x86_64" like it has been in the previous RemoteMaster version.

Michael

Barf · Post by **Barf** » Tue Nov 13, 2012 3:10 pm

I wrote down my observations, because sooner or later it may bite, possibly with an obsolete version and an inexperienced user.

DecodeIR 2.43 comes with "Mac OS X-X86_64", as does IrMaster 0.3.0. This worked for me with Snow Leopard, but after upgrading to Mountain Lion, it did not any longer, which I with some effort identified to the above mentioned problem. I do not think I made a mistake.

Unfortunately, I do not have access to the old system any longer; the update overwrote it.

I would stay with the directory name "Mac OS X-x86_64" like it has been in the previous RemoteMaster version.

Agreed. I have changed my loading code (in IrpMaster.DecodeIr.java) to read

Code: Select all

 + System.getProperty("os.arch").toLowerCase(Locale.US);

and would suggest the RM maintainers to do likewise.

Post by **mathdon** » Wed Nov 14, 2012 7:21 am

Barf wrote:I have changed my loading code (in IrpMaster.DecodeIr.java) to read
Code: Select all
 + System.getProperty("os.arch").toLowerCase(Locale.US);
and would suggest the RM maintainers to do likewise.

I have made this change to my development code, so that it will be in the next v2.03 Alpha version.

Barf · Post by **Barf** » Wed Feb 13, 2013 3:34 pm

Just uploaded a version compiled for the Raspberry Pi. I am using Raspian, with Hardware FP support. (Using Raspian 2013-02-09.)

mdavej · Post by **mdavej** » Thu Apr 10, 2014 9:14 am

I have a huge spreadsheet full of pronto hex codes from Denon and would like to use DecodeIR to find all the OBCs. Is it possible to use the dll from Excel in VBA? If so, could anyone provide some example code?

If not, what's the easiest way to bulk decode a lot of pronto hex? Barf, if Scrutinizer can do it, could you point me in the right direction?

If there is an easier way to achieve my goal, please let me know.

Thanks

Barf · Post by **Barf** » Thu Apr 10, 2014 11:08 am

For sure, IrScrutinizer can do it, although not quite in one step (at least not presently). It can import one worksheet at a time. To do so, just copy the the worksheet to the clipboard (no fumbling necessary, just Ctrl-A Ctrl-C suffices). In IrScrutinizer, go to Import->Text->Raw, leave Name column to 1, and raw signal column at 2, and (important!) select TAB as Field separator. Then just press "Load from clipboard" and you have it in the tree. Press Import all, and press OK in the popup. which takes you to the parametrized remote panel. You can now either import another worksheet (they will all be added up in the parametrized remote pane), or you can re-export in one of may formats. RM is not one of them, however, here i published an improvement to RM enabling it to import Girr-files, which is the native format of IrScrutinizer.

Let me know if you need more detailed instructions.

Having IrScrutinizer import Excel files directly, even multi-worksheet like the current file, would be do-able (Apache POI), but I have presently no plans. But who knows?

mdavej · Post by **mdavej** » Thu Apr 10, 2014 1:15 pm

Sounds good. I'll give it a shot. Thanks

Unless you gets lots more requests, I wouldn't bother with excel import. This is the first time in over ten years or JP1-ing I've had a need for such a thing.

One thing I could do quite easily, I think, is have excel output the codes in Girr format. I may try that first.

mdavej · Post by **mdavej** » Fri Apr 11, 2014 8:23 am

Worked great. Got a couple hundred codes converted in just a few minutes using copy/paste method. Didn't try Girr method.

Thanks