JP1 Remotes

I recently moved to Windows 7 x64. I have a Tyler cable for various remotes and a Nevo C2. Everything worked under XP32 on version 2.03 build 14.

Setting up this machine, I installed the latest RMIR, Java JRE 1.8-111 x64 and the recommended FTDI driver 2.10.0.0 from here. The driver detects the cable and works.

When I loaded a file, made a slight change and attempted to upload to my RCA remote, the program dumped immediately. The Java error log looks like:

# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000058ea7c29, pid=4052, tid=0x0000000000000ec0
#
# JRE version: Java(TM) SE Runtime Environment (8.0_111-b14) (build 1.8.0_111-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.111-b14 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C [ftd2xx.dll+0x7c29]

The RMIR error log stopped logging at:
Interface Name = NULL
Port Name = NULL
Testing interface: JP1.X Serial

If I manually set the correct interface, it works, up and download, both with JPx and Nevo remotes. I can set it back to auto and it will continue to work until I switch remotes to one with a different interface, and then it crashes again.

I will go out on a limb and guess that this is happening because I haven't installed some driver that I don't/haven't used.

I can work around this obviously, but I have to be careful not to lose my work ...

The XP32 machine had v. 2.6.0 of the FTDI driver. The latest version on the FTDI site is 2.12.24. I tried both of these, behavior is exactly the same on all three versions.

This doesn't happen under 32-bit Java, so the problem must be in the 64-bit libraries.

So here is a fix for others with this problem: You can install 32-bit Java with defaults and it will coexist with the 64-bit Java. Change/create a new shortcut for RMIR that point to java.exe in "Program Files (x86)" instead of "Program Files", and then it will run under the 32-bit Java. Verify by reading the Help/About dialog in RMIR.

MrMoody wrote:This doesn't happen under 32-bit Java, so the problem must be in the 64-bit libraries.

The libraries used by RMIR to read/write to the Nevo were not written by us. They are part of hidapi 1.1, which is incorporated into the RMIR jar file. So if there is a bug, I'm afraid we are not in a position to fix it.

ft2dxx.dll is part of the FTDI serial driver. The crash happens when the Nevo is not plugged in (it was the RCA the first time, but it also crashes with no remote). Letting it auto-detect crashes it every time. What makes you think it's hidapi?

My suspicion is most people haven't hit this because they are using 32-bit Java on 64-bit Windows.

I just thought of something else to try ...
... Unplug the FTDI cable from the USB, it does NOT crash.
... RMIR 2.03-14 64-bit (which shows CommHID 0.4 and jp12serial .20) also crashes with the FTDI cable in the USB.

It's something in the auto-detect process that's breaking whatever is breaking; as I said, it works perfectly INCLUDING the FTDI cable and any remote, if you don't let it auto-detect.

Giving up and sticking to 32-bit for now.

I would like to know if anyone is using the 64-bit version (check Help-About for os.arch="amd64") with the FTDI cable/driver and doesn't have this problem.

I'm using Windows 10, with 64 bit Java. It works with both 2.03 and 2.04. I have seen this error once, but it turned out to be my error. In my case, simply running setup.vbs fixed it. I tried that because an application error (e.g. an error in RMIR) should not cause a Java crash.

3FG wrote:I'm using Windows 10, with 64 bit Java. It works with both 2.03 and 2.04. I have seen this error once, but it turned out to be my error. In my case, simply running setup.vbs fixed it. I tried that because an application error (e.g. an error in RMIR) should not cause a Java crash.

Are you sure setup.vbs didn't flip you to 32-bit Java? Double-checked About?

What version of the FTDI driver are you using?

I have used both .10 and .12 versions of the FTDI driver under 64 bit Windows and 64 bit Java. I'm traveling for the next several days, so I can't directly verify this, but I will point out that it was necessary to use 64 bit Java during the development of RMIR for the URC7980 remote, because JP12Serial.dll was only compiled in a 64 bit version from build 6 through build 8. Note that if one uses 32 bit Java to run RMIR, it will load the 32 bit dlls, so we can be sure that 7980 users were using a USBtoSerial cable under 64 bit Java.

However, my suggestion to just click on Setup.vbs won't necessarily work. I looked at the script, and depending on the previous state of the computer, it may (or likely will) setup RMIR to run under 32 bit Java. I think we need to update Setup.vbs, especially removing references to Java 1.6.