Yes. I was getting confused by Mark continuing to mention Java Control Panel and Update Now. Update Now will never update to anything beyond Java 8. It is not an error, it is simply obsolete.The Robman wrote:RMIR shows 24.0.1, doesn't that confirm that he already has 24.
Weird RMIR behaviour - 2 Roku upgrades
Moderator: Moderators
mathdon wrote:"Update now" DOES NOT WORK ANY LONGER. Ignore it and install Java 24. It is a jdk, there are no more separate runtime versions.mathdon wrote:Because Oracle changed everything from Java 9 onward, including any links such as "Update now".chileboy wrote:And why doesn't the "Update now" button in the Java CP find the newer version?
Well, I'm confused because I keep being told to update to JDK 24 which I have - more than once - yet also being told that doing so would update my "obsolete" JRE 8, which obviously it has not.mathdon wrote:Yes. I was getting confused by Mark continuing to mention Java Control Panel and Update Now. Update Now will never update to anything beyond Java 8. It is not an error, it is simply obsolete.The Robman wrote:RMIR shows 24.0.1, doesn't that confirm that he already has 24.
- Mark
-
The Robman
- Site Owner
- Posts: 22056
- Joined: Fri Aug 01, 2003 9:37 am
- Location: Chicago, IL
- Contact:
You are up to date with Java, Mark, you issue lies elsewhere.
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
I don't know what you were expecting to happen with "updating your obsolete JRE 8". It clearly HAS been updated as RMIR now shows you are using Java 24. Perhaps you don't realize that you can have several versions of Java on your machine at the same time. I have jdk1.8.0_221 (Java 8), jdk14.0.2 (Java 14) and jdk24.0.1 (Java 24) on mine. On an earlier machine I had Java 6, Java 7 and Java 8 so this is not a new feature. The one in use at any time is determined by the Environment Variables, in particular Path and JAVA_HOME. Hope this helps.chileboy wrote:I keep being told to update to JDK 24 which I have - more than once - yet also being told that doing so would update my "obsolete" JRE 8, which obviously it has not.
Graham
-
SysTech_Larry
- Posts: 305
- Joined: Thu Oct 19, 2023 12:43 am
- Location: Northern Wisconsin, USA
- Contact:
It is neither recommended nor not recommended, it is simply unnecessary and of no significance. Multiple Java versions can exist simultaneously, they do not interfere with one another. You can uninstall one you never intend to use again if you wish, but you do not need to do so.SysTech_Larry wrote:I uninstalled 8 after I installed 24. Is that not recommended?
Graham
-
lbschenkel
- Posts: 15
- Joined: Sun Sep 13, 2015 7:59 am
Re: Weird RMIR behaviour - 2 Roku upgrades
I have independently encountered this same issue when trying to add a 2nd device with the same protocol as an existing upgrade. The 2nd one would always be overwritten with the device/subdevice of the first. After struggling a lot with this I found out what the issue was, it's a bug in RMIR, I submitted the bug (and a fix) here: https://sourceforge.net/p/controlremote/bugs/46/
In the meantime until this gets fixed, a workaround: if you enable "use non-modal device editor" in Options|Advanced then this problem disappears.
In the meantime until this gets fixed, a workaround: if you enable "use non-modal device editor" in Options|Advanced then this problem disappears.
Re: Weird RMIR behaviour - 2 Roku upgrades
1. I uploaded this file. It contains two device upgrades, both using the NEC1 (005A) protocol. The DVD has device number 73. The "Cable" has device 108 and subdevice 104. Opening the DVD from the "General" tab is ok. Opening it from the "Devices" tab, and the device is suddenly 108, and there is a subdevice of 104 (the values from the other device upgrade): So the bug exists. Q.E.D.
2. I have tried Leonardo's patch, and it does not work at all, for example it "hangs" (sort of) when selecting the Devices tab.
3. I spent some time with the code. 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. It appears to be deeply used in the code, so it may be pretty involved to fix. (Protocol.getDeviceParmValues() has 14 usages...). Graham, are you there?
2. I have tried Leonardo's patch, and it does not work at all, for example it "hangs" (sort of) when selecting the Devices tab.
3. I spent some time with the code. 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. It appears to be deeply used in the code, so it may be pretty involved to fix. (Protocol.getDeviceParmValues() has 14 usages...). Graham, are you there?
-
lbschenkel
- Posts: 15
- Joined: Sun Sep 13, 2015 7:59 am
Re: Weird RMIR behaviour - 2 Roku upgrades
Not sure what went wrong with your system. I'm quite sure the fix works, even if it doesn't it simply cannot make the UI hang, plus the very same code has been incorporated into the latest RMIR release.Barf wrote: Wed May 06, 2026 4:14 am 2. I have tried Leonardo's patch, and it does not work at all, for example it "hangs" (sort of) when selecting the Devices tab.
Re: Weird RMIR behaviour - 2 Roku upgrades
I apologize for not giving a more precise bug description. However, consider the bug here. It appears to have your fix involved.
Setting a breakpoint in DeviceUpgrade( DeviceUpgrade base, DeviceButton newRestriction ) show that on line 152 parmValues gets a vector of length 0; previously it was a length 5 value.
If the refresh code in a table throws an exception, it can be called repeatedly, creating an apparent "hang".
Setting a breakpoint in DeviceUpgrade( DeviceUpgrade base, DeviceButton newRestriction ) show that on line 152 parmValues gets a vector of length 0; previously it was a length 5 value.
If the refresh code in a table throws an exception, it can be called repeatedly, creating an apparent "hang".