JP1 Remotes

Posted: **Wed May 14, 2025 3:45 pm**

The project doc on Source forge just mentions Java 8+ . Obviously, there have been many versions of the JDK/JRE since then. And there are multiple distributions, such as Oracle Java and OpenJDK, etc.

I have run into strange bugs with RMIR, and the behavior for these bugs is unfortunately different depending upon the version of Java installed. For instance, I just had a remote I could not load after editing and doing a "save as" when using Java 20. I was getting "Error loading file" on the new copy. I upgraded to Java 24, and the problem with reload is gone, though there are still drawing/repaint problems in the GUI. But at least I can edit it.

FYI, that RMIR file is at https://drive.google.com/file/d/1Jk2PDl ... drive_link . I believe it was last saved with RMIR 3.0.3 . It fails to load after "Save as" in RMIR 3.2.0 using Oracle Java 20 on Windows.

So, my question is, which version of Java is the current maintainer of the project using ? I'd like to use the same one. It would probably be useful information to have in the distribution/readme for future versions going forward.

I know that Java in theory is supposed to be "write once, run anywhere". But in practice, it's also "write once, debug everywhere", unfortunately. Having done a lot of cross-platform development myself, though never in Java, I unfortunately think this is unavoidable. But at least some issues with the debugging part could probably be mitigated/skipped by using the same version as the maintainer uses for development.

Posted: **Thu May 15, 2025 3:37 am**

I do not think this is a good path to follow. It is more likely to spread questionable rumors than to generate true knowledge. There are supported versions, and if the program misbehaves using a supported version, it is a bug. Bugs are fixed. You have posted problematic configurations, and have had the problems identified for you.

There are so many variables involved. Trying to associated a certain problem with JVM versions is may be helpful when debugging a problem, but it is unlikely that the conclusion will be that version x.y from $VENDOR is buggy.

Having said that, using RMIR 3.2.3 using java 21.0.7 from Red Hat, Inc (which is OpenJDK i guess) on 64-bit Linux (Fedora 42), I can load then linked file, save it, but not read the just saved file. Do you need help in debugging?

Posted: **Thu May 15, 2025 5:34 am**

Barf wrote:I do not think this is a good path to follow. It is more likely to spread questionable rumors than to generate true knowledge. There are supported versions, and if the program misbehaves using a supported version, it is a bug. Bugs are fixed. You have posted problematic configurations, and have had the problems identified for you.

There are so many variables involved. Trying to associated a certain problem with JVM versions is may be helpful when debugging a problem, but it is unlikely that the conclusion will be that version x.y from $VENDOR is buggy.

All I want is to eliminate a variable, which is a potential source of bugs, namely the platform/JVM being used.

In my software engineering career that spanned over 3 decades, it was standard practice to build, test and certify software on specific platforms, and the products were always documented and advertised that way. This was for native binaries, not Java. Some OS vendors tried to achieve backwards compatibility. They sometimes succeeded. They also failed. Sometimes they just needed to be bug-compatible indeed to achieve compatibility. But I digress. All I am asking for is what platforms the software was actually tested on. That's a useful piece of information.

Having said that, using RMIR 3.2.3 using java 21.0.7 from Red Hat, Inc (which is OpenJDK i guess) on 64-bit Linux (Fedora 42), I can load then linked file, save it, but not read the just saved file. Do you need help in debugging?

Yes, I need help debugging it. I am seeing the same thing again now. It was working earlier yesterday, but not anymore. That makes it an intermittent bug. I wrongly assumed that the bug was tied to the JVM version, but it's just a bug of random occurrence. I'd love to know what's wrong with the configuration that causes this.

I tried to roll back to 2.13.2 to load the "master bed 3" remote and make changes. I failed in different ways. I was unable to add a device successfully . After using Devices / New / Open, and loading an RMDU, the new device showed up in the "Devices" tab, but did not show up in the "General" tab. I can save the file and reopen it in 2.13.2, but that does me no good since I can't complete my edits.

If I load "master bed 3" and do the Devices / New / Open using 2.13.2 , the device shows up in both the General and Devices tab. But after that, save / reopen fails, so there is no point in trying to do the edits on 3.0.3 .

I'd love to know what's in this config that is giving RMIR trouble. There are a lot of possibilities. It could be some of the device upgrades. Or it could be the activities macros. There isn't much else in this remote. The device upgrades can be saved/loaded separately, but the activities cannot be. That makes it tedious to recreate the remote from scratch to work around these bugs. Better to identify them first.

Posted: **Thu May 15, 2025 6:55 am**

madbrain wrote: Yes, I need help debugging it. I am seeing the same thing again now. It was working earlier yesterday, but not anymore.

So, using 3.2.0, a few independent tests I did, starting with the master bed 3 remote file each time :
1. deleting all activities and devices / saving / reloading succeeds
2. deleting all the activities / saving / reloading still fails
3. deleting all 6 devices causes the saving operation to fail. The reason is not stated. This may be because the activities are still referencing commands in them
4. deleting devices 4/5/6 / saving / reloading still fails
5. deleting device 1 (TV) / saving / reloading still fails
6. deleting device 2 (AVR) / saving / reloading succeeds !

So, it looks like the AVR device may be at fault.

I did the following .
a. I reloaded the original remote, "master bed 3"
b. I saved the device upgrade for the Marantz AVR.
c. I deleted the AVR device
d. I re-created the AVR device
e. I opened the device upgrade from step b . This time, the new device showed up in both General and Devices tabs.
f. However, I noticed that two of the functions were missing in the new device : #4 "SYSTEM POWER OFF", and #32 "PC" .

I manually inspected the avr.rmdu file, and found that these 2 functions were not saved into the device upgrade file in step b.

The "PC" function was a duplicate of the "BD (code 2)" function, so perhaps that played a role in it not being saved.

But I can't explain why the "SYSTEM POWER OFF" function did not get saved.

Removing the original AVR device means that I have to manually fix almost all activities to re-insert the input selection command in the macros.

Posted: **Thu May 15, 2025 8:50 am**

madbrain wrote:Yes, I need help debugging it.

So, I fired up the debugger (netbeans 20) on the current SVN sources, and tried to load the save I created in the previous post. Turn out that line #3099 in DeviceUpgrade.java was the culprit:

Code: Select all

          if ( f.getGid() == 0 || ff != null && !f.getHex().equals( ff.getHex() ) )

Here f.getHex() was returning null, so evaluating f.getHex().equals(...) bombed. Replacing that line as

Code: Select all

Index: src/main/java/com/hifiremote/jp1/DeviceUpgrade.java
===================================================================
--- src/main/java/com/hifiremote/jp1/DeviceUpgrade.java (revision 2187)
+++ src/main/java/com/hifiremote/jp1/DeviceUpgrade.java (working copy)
@@ -3096,7 +3096,7 @@
         if ( f.getGid() != null )
         {
           Function ff = keyGidMap.get( f.getGid() );
-          if ( f.getGid() == 0 || ff != null && !f.getHex().equals( ff.getHex() ) )
+         if ( f.getGid() == 0 || ff != null && f.getHex() != null && !f.getHex().equals( ff.getHex() ) )
           {
             int newGID = getGidForName( f.getName() );
             f.setGid( newGID );

and the save can be loaded. This is, strictly speaking, a bugfix for RMIR. (Independent on the JVM version

.)

It appears that the two last functions for the Marantz were missing names, which was triggering the problem.

If you need a RemoteMaster.jar with this fix let me know.

Posted: **Thu May 15, 2025 3:41 pm**

Barf wrote:
madbrain wrote:Yes, I need help debugging it.
So, I fired up the debugger (netbeans 20) on the current SVN sources, and tried to load the save I created in the previous post. Turn out that line #3099 in DeviceUpgrade.java was the culprit:
Code: Select all
          if ( f.getGid() == 0 || ff != null && !f.getHex().equals( ff.getHex() ) )
Here f.getHex() was returning null, so evaluating f.getHex().equals(...) bombed. Replacing that line as
Code: Select all
Index: src/main/java/com/hifiremote/jp1/DeviceUpgrade.java
===================================================================
--- src/main/java/com/hifiremote/jp1/DeviceUpgrade.java (revision 2187)
+++ src/main/java/com/hifiremote/jp1/DeviceUpgrade.java (working copy)
@@ -3096,7 +3096,7 @@
         if ( f.getGid() != null )
         {
           Function ff = keyGidMap.get( f.getGid() );
-          if ( f.getGid() == 0 || ff != null && !f.getHex().equals( ff.getHex() ) )
+         if ( f.getGid() == 0 || ff != null && f.getHex() != null && !f.getHex().equals( ff.getHex() ) )
           {
             int newGID = getGidForName( f.getName() );
             f.setGid( newGID );
and the save can be loaded. This is, strictly speaking, a bugfix for RMIR. (Independent on the JVM version .)

It appears that the two last functions for the Marantz were missing names, which was triggering the problem.

If you need a RemoteMaster.jar with this fix let me know.

Thank you very much for the investigation.

I would also like to understand which functions were missing names, and where I could have entered them in the GUI to work around this bug. Were those the SYSTEM POWER OFF and PC functions ?

I would very much like the fix, also.

Thanks !

Posted: **Fri May 16, 2025 2:02 am**

I tried to upload RemoteMaster.jar, but it (< 10MB) was too big for this forum.

Instead it is available here.

madbrain wrote:I would also like to understand which functions were missing names,

Your master bed 3.rmir contains the lines

Code: Select all

Function.153.name=
Function.154.name=

which I guess is the cause of the problem. Possibly they were at the end of the function table and you did not see them.

Posted: **Fri May 16, 2025 2:29 am**

Barf wrote:I tried to upload RemoteMaster.jar, but it (< 10MB) was too big for this forum.

Instead it is available here.

madbrain wrote:I would also like to understand which functions were missing names,
Your master bed 3.rmir contains the lines
Code: Select all
Function.153.name=
Function.154.name=
which I guess is the cause of the problem. Possibly they were at the end of the function table and you did not see them.

Thank you very much for the fix !

Indeed, they were at the end of the table in the device upgrade for the Marantz AVR. I don't know how they ended up there. Maybe accidentally pressing the "New" button in the past. However, they weren't causing problems before, or "master bed 3" itself would not have been loadable.

I have run into problems with several other remote images as well, and unfortunately they don't seem to be related to this particular bug. The issue that is immediately observable is that there are repaint problems in the GUI when the file is open. For instance, the General tab is not painted at all, or repainted when moving to say, the Devices tab, back to the General tab.

a. a 2022 remote image for my guest bedroom

guestroom.rmir at https://drive.google.com/file/d/1UBM3Q0 ... sp=sharing .

I ran into many other problems when editing, besides the display bug, and had to recreate the remote from scratch as a result, as it wasn't possible to fix it on top of the existing file. It was hours and hours of work. I wish I wrote all the gory details down.

b. a 2023 remote image for my home theater

https://drive.google.com/file/d/1_L3oK2 ... sp=sharing

This one has the display problem as well, but was still editable. But even my latest working remote image still suffers from the display problem.

c. a brand new "empty" image created after doing a factory reset of my remote, and "download remote".

https://drive.google.com/file/d/1w2jzRN ... sp=sharing

Come to think of it, most of my remotes are having display / repaint problems upon opening.

One exception is the remote I rebuilt for the guest room.

https://drive.google.com/file/d/1Lr_dCX ... sp=sharing

Posted: **Fri May 16, 2025 5:12 am**

All of these files trigger the same problem. For some reason, some DirecTV_rf setting is not properly initialized, and trying to get the content for the Settings table triggers a null pointer exception. (Isn't it cute: Java has no pointers, but it has null-pointer exceptions

). I have no idea what this is intended to do (Graham, mdavej?) Anyhow, this problem is fixed by:

Code: Select all

Index: src/main/java/com/hifiremote/jp1/SettingsTableModel.java
===================================================================
--- src/main/java/com/hifiremote/jp1/SettingsTableModel.java    (revision 2187)
+++ src/main/java/com/hifiremote/jp1/SettingsTableModel.java    (working copy)
@@ -151,6 +151,11 @@
           NamedHex nh = remoteConfig.getSSDHexSettings()[ row ];
           if ( nh.getName().equals( "directv_rf" ) )
           {
+           if ( nh.getHex() == null )
+            {
+              System.err.println("DEBUG: Silly nh.getHex detected, just outputting 0");
+              return String.format( "%06d", 0 );
+            }
             short[] hexData = nh.getHex().getData();
             int rfInt = 0;
             for ( int i = 0; i < 4; i++ )

I have updated the RemoteMaster.jar to contain this fix too.

Posted: **Fri May 16, 2025 9:08 am**

I can tell you that DirecTV RF being initialized (present) or not are both normal conditions. If the user never sets up DirecTV RF on the remote, then the setting won't be in the file (I presume). So if either case throws some sort of exception, it needs to be handled. So, thank you Barf for that fix.

Keep in mind that the last DirecTV receiver that used this kind of RF was discontinued 20 years ago. So virtually nobody will ever enable it on their remote unless they just do it accidentally. So the "not initialized" case is the normal case.

Graham, if you have any thoughts on handling this differently, please let us know.

Posted: **Wed May 21, 2025 4:38 am**

Graham, OK to check in these two fixes? I do not think they have side effecta, but there may be another way?

Posted: **Tue May 27, 2025 1:18 am**

Graham, you probably did not see, or forgot this; I want you're OK to check in the two fixes.

Posted: **Tue Jun 03, 2025 3:42 am**

Checked in. Although I changed "silly" to "null"

JP1 Remotes

Which JDK provider/version is recommended for Remote Master

Which JDK provider/version is recommended for Remote Master