#43 "Error loading file" when it contains DSMs bound to shifted keys

2026-05-11T08:32:57.956000Z

To be honest I don't completely remember the context anymore after all this time. I think my intent back then was to create a controlled DSM and RMIR was misbehaving for some reason, but as previous comments stated this is a real-time DSM (unsure what is the actual difference in practice between them in this particular remote); I am not sure if the use of real-time here was my mistake or a genuine bug in RMIR. Anyhow, the fact that RMIR can open the file now and warn about it indicates to me that the original problem of not being able to load the file was fixed.

#43 "Error loading file" when it contains DSMs bound to shifted keys

2026-05-08T12:39:50.366000Z

If you open test.rmir in a recent RMIR version, the latest release being v3.2.16 but I think any v3.2 build will do, it will open and you will see that the DSM in test.rmir is NOT a controlled DSM, it is a real-time DSM. The only valid key that you can assign a real-time DSM to is NetTV. It is possible for testing purposes to turn off the validation by selecting the menu item Advanced > Disable Upload Restrictions. If you do so, create an entry and then deselect this item, the created entry will be highlighted in purple. By using an old version of RMIR you have managed to assign a real-time DSM to Shift-Play, which is why it now gets highlighted in purple. If you create a real controlled DSM then you CAN assign it to a shifted key with v3.2.16 or other recent builds.

#37 Bug with keymoves with NEC1 Combo

2026-05-08T11:53:55.812000Z

status: open --> closed
Group: --> v0.27

#46 Protocol parameters overwritten by RMIR

2026-05-08T11:44:11.748000Z

This fix is now included in RMIR v3.2.16, posted yesterday.

#39 ModeName Special Function

2026-05-07T11:14:30.533000Z

status: pending --> closed

#40 Missing map and image for URC-2025 and problem with RDF

2026-05-07T10:26:09.922000Z

status: open --> closed

#44 v3 & lost icons on remote

2026-05-07T10:15:26.571000Z

status: open --> closed

#41 Can't install under XP

2026-05-07T10:09:51.167000Z

status: open --> closed

#45 Some Help menu entries dead since the demise of hifi-remote.com/forums

2026-05-07T10:07:57.396000Z

status: open --> closed

Protocol parameters overwritten by RMIR

2026-05-05T06:08:39.293000Z

I independently have encountered the same problem reported in https://www.hifi-remote.com/forums/viewtopic.php?t=103894:

It manifests in the following forms:

once you submit a device upgrade, even if it's the only one, you can no longer edit the protocol parameters (they revert back to previous values when the editor closes)
if you have multiple upgrades using the same protocol, the parameters are always overwritten with the values from the first one
if you edit the file manually instead, and open it, the values stay as in the file until you attempt to edit the upgrade, then the problems happen again

Strangely enough, I also stumbled upon a workaround: if Options/Advanced/Non-model editor is turned on, the problems above do not manifest. Turn if on again, and they come back.

After struggling a lot with the above I decided to run RMIR under a debugger and diagnose what was happening (I am a Java developer). And I found out what the issue was:

The problem is that protocol parameters while they're being edited are both live and global state, they're components from the protocol device parameters being shown in the UI that are per-protocol and protocols are global. And when new instances of the class DeviceUpgrade are created, they try to clone the protocol parameter values of the upgrade by using the protocol device parameters, and that overwrites the values in those components.

One of the code paths that creates new device upgrades is the renderer of the device upgrade table in the Devices tab. When the table needs to be refreshed, it will clone the upgrades from the model in order to update the UI.

When non-modal editor is OFF (the default), and you launch the device upgrade editor, it will disable the parent window (containing the device upgrade table), open the editor, and when you press OK one of the first things it will do is to re-enable the parent window.

When the parent window is re-enabled, Swing will trigger a refresh/re-render of the table component. That will invoke the code path trying to clone the existing device upgrades, and the first entry in the table that has the same protocol will result in that code path cloning the previous values (the ones in the model, in the pre-edited state) and overwriting the values entered in the device upgrade editor. This happens very early, before the values are actually processed and the model is updated, so any changes the user have made are reverted back.

When non-modal editor is ON, then the parent window is never re-enabled and that does not trigger any table refresh at that point. The problematic code path is not invoked, the values are actually processed and the data models are updated, and then the table is refreshed, with the problematic code path being invoked, but now the models are actually containing the post-edited state so that is fine.

I am attaching a patch that addresses this problem. It changes the DeviceUpgrade cloning code so it never attempts to use the protocol device parameters (and their components):

diff --git a/src/main/java/com/hifiremote/jp1/Value.java b/src/main/java/com/hifiremote/jp1/Value.java
--- a/src/main/java/com/hifiremote/jp1/Value.java   (revision 2240)
+++ b/src/main/java/com/hifiremote/jp1/Value.java   (date 1777961033694)
@@ -1,6 +1,9 @@
 package com.hifiremote.jp1;

 // TODO: Auto-generated Javadoc
+
+import java.util.Arrays;
+
 /**

  * The Class Value.
  */
@@ -39,6 +42,18 @@
     this.defaultValue = defaultValue;
   }


+  public Value copy()
+  {
+    return new Value( userValue, defaultValue );
+  }
+
+  public static Value[] copy( Value[] values )
+  {
+    return Arrays.stream( values )
+        .map( Value::copy )
+        .toArray( Value[]::new );
+  }
+
   /**
    * Gets the user value.
    *

diff --git a/src/main/java/com/hifiremote/jp1/DeviceUpgrade.java b/src/main/java/com/hifiremote/jp1/DeviceUpgrade.java
--- a/src/main/java/com/hifiremote/jp1/DeviceUpgrade.java   (revision 2240)
+++ b/src/main/java/com/hifiremote/jp1/DeviceUpgrade.java   (date 1777621985560)
@@ -139,8 +139,17 @@
     // copy the device parameter values
     if ( base.protocol != null )
     {
-      protocol.setDeviceParms( base.parmValues );
-      parmValues = protocol.getDeviceParmValues();
+      // *DO NOT* call protocol.setDeviceParams() here to clone parmValues!
+      // Protocol device params are global state, and may be:
+      // - live: currently rendered in the UI; and/or
+      // - dirty: containing user-entered input which has not been saved yet.
+      //
+      // Violation of this rule will result in this code path overwriting
+      // user-entered protocol parameters. For example, if the table showing
+      // device upgrades is re-rendered while the upgrade dialog is open,
+      // the old values in the table data will overwrite any changes the user
+      // has typed.
+      parmValues = Value.copy( parmValues );
     }

     // Copy the functions and their assignments

This completely addresses the problems described. I kindly ask for this fix (or an equivalent one) to be added to RMIR. Thank you.

Recent changes to bugs

#43 "Error loading file" when it contains DSMs bound to shifted keys

#43 "Error loading file" when it contains DSMs bound to shifted keys

#37 Bug with keymoves with NEC1 Combo

#46 Protocol parameters overwritten by RMIR

#39 ModeName Special Function

#40 Missing map and image for URC-2025 and problem with RDF

#44 v3 & lost icons on remote

#41 Can't install under XP

#45 Some Help menu entries dead since the demise of hifi-remote.com/forums

Protocol parameters overwritten by RMIR