Re: Weird RMIR behaviour - 2 Roku upgrades
Posted: Fri May 15, 2026 4:38 am
The fix included in RMIR v3.2.17 was provided by user lbschenkel. In DeviceUpgrade.java it includes the following:Barf wrote: Fri May 15, 2026 3:29 am I cannot reproduce the problem I reported, so it appears to have been fixed. Still, I have a bad feeling about the code, as I described in my previous post. Since there are now no known and documented bugs(?), I do not recommend an immediate fix though.
Code: Select all
// copy the device parameter values
if ( base.protocol != null )
{
// *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( base.parmValues );
// protocol.setDeviceParms( base.parmValues );
// parmValues = protocol.getDeviceParmValues();
}I believe that with this fix, there is no problem with having the actual device parameters being in the Protocol class. After all, their presence is not a recent change and as far as I can see, there are many upgrades that use the same protocol with more than one set of device parameters. I cannot recall any problems with it being reported previously.As I see it, the fundamental problem is that the actual device parameters is present in the Protocol class, where it does not conceptually belong; it belongs to the DeviceUpgrade class.