RMIR v3.0 Major new release!

[mathdon]

RMIR v3.0.12 is now officially released. This is the first official release since v3.0.10, as build 11 was for development purposes.

The changes since v3.0.10 are:

1. The included IrpTransmogrifier has been upgraded from v1.2.12 to v1.2.13 and correspondingly Girr has been upgraded from v2.2.12 to v2.2.13. This version incorporates the protocol amendments and new protocols that were in the patch file rmProtocols.xml in RMIR v3.0.10.

2. A new protocol, Amazon Fan, has been added to protocols.ini and is also included in the new IrpTransmogrifier.

3. Support has been added for a new format for DSMs in JP1.3 and earlier remotes, first seen in the JP1.2 remote REM48TVB, signature 10531053.

4. The RDFs for the REM48TVB and Niles R8L have been updated and one for the Atlas 1056 B04 has been added.

5. A bug present since RMIR v3.0.0 has been fixed that caused internal Special Protocols created in these RMIR versions to be listed twice on the Special Functions tab when downloaded.

6. The messages displayed when no matching RDF is found now provide links to the RDF-Development and RDF-Archive folders in a browser.

7. The revised instructions.txt file for the JP1EEPROMSupport folder that adds the additional steps required if using the Arduino JP1 interface with Windows 11 is now included in this RMIR version. They were previously posted separately.

8. Certain error situations that would cause RMIR to crash are now caught and display error messages instead.

[n8nagel]

Good morning everyone!

I just installed 3.0.12 for the first time - I am setting up a new PC that I just got, my memory and hard drive showed up Thursday so this weekend I'm installing software and testing everything. Anyway, this is the first time I've used any v3.0 version; I held off initially because all my remotes are Xsight Colors, then after that because I just got busy and wasn't doing a lot of decoding of new devices, I think I've only done two since v3.0 came out, and one of those I need to go back and make better.

Anyway, here's my question. When I ran setup.vbs (I am on Win10 Pro) it mentioned that I could enter a scale factor if I wanted, I did not because I didn't have any issues with the previous versions, but now the text is VERY small. I'm using two 4k monitors with Windows scaling to 150%. When I started RMIR for the first time the text is VERY small.

1) is there a way to change that scale factor within the program?
2) is there any harm running setup.vbs again after it's been run before?

Thanks! (and thanks for keeping this going, I literally do not know what I would do without RMIR and IRScrutinizer, probably cuss and spend more money on vintage remotes than I already do.)

Edit: I just installed MakeMKV and am having the exact same problem, I can barely read the text it's so small! I am guessing that it uses Java as well?

Edit 2: Same thing is happening with VLC. So it is definitely not a RMIR specific problem.

[Barf]

1) is there a way to change that scale factor within the program?

No.

2) is there any harm running setup.vbs again after it's been run before?

I think this will work, if not please report so that we can fix it. You can also right click on the icon and edit the command line, squeezing in -Dsun.java2d.uiScale=2 (or whatever) as argument to the JVM, not the program.

The completely correct and complete solution to this problem is unknown to me. cf this issue on IrScrutinizer.

I recently discovered that it is possible to give the Dsun.java2d.uiScale spell in the program, before constructing the GUI, so that the scaling parameter can be given as argument to the program, not the JVM. This is implemented in IrScrutinizer since late December last year, see IrScrutinizer.java, line 105. This is slightly more flexible for the user. I would recommend doing this in RMIR too.

[n8nagel]

Thank you for the reply! I have found the same issue with MakeMKV and VLC as well. IRScrutinizer must have been fixed as that one is working fine for me. So, I guess I know what I'll be playing with today.

[mathdon]

RMIR v3.0.15 is now officially released. This is the first official release since v3.0.12, as builds 13 and 14 were for development purposes.

The changes since v3.0.12 are:

1. RDFs have been added for (a) Comcast-URC-1058(old), differing from Comcast-URC-1058 in its Fixed Data byte, (b) Movistar 6740BA0, (c) URC-1210 Contour TV v2, together with Map and Image files for (b) and (c).

2. Support for long press of FastFwd and Rewind has been added to the RDF and Map files for URC-1240 v2, URC-1280 v2, URC-2981, all with signature 368001.

3. An Initial Device Mode setting has been added to the RDF for REM48TVB.

4. There are additions to protocols.ini for S3C80 code for PID=0202 and for a new protocol "Sharp Old", with corresponding additions to rmProtocols.xml for "Sharp Old".

5. A correction has been made to rmProtocols.xml for Denon and Sharp protocols.

6. The Help file "IrpTransmogrifier Protocols" has been updated to correspond to the changes to rmProtocols.xml.

7. The digitmaps.bin file has been updated to v769.

8. The ability to change minimum leadout has been added when decoding learned signals with IrpTransmogrifier.

9. Bugs have been fixed in the handling of (a) Activity Power macros, (b) Activity Highlights in remotes that used to use EZ-RC, (c) Activity Macros in XSight Touch and related remotes, (d) saving setups for remotes that use Activity Help, such as URC-7960, (e) RMIR started from the command line with an rmir file without directory as argument, (f) Girr export of a device update with an empty "Description" field.

[mathdon]

I recently discovered that it is possible to give the Dsun.java2d.uiScale spell in the program, before constructing the GUI, so that the scaling parameter can be given as argument to the program, not the JVM. This is implemented in IrScrutinizer since late December last year, see IrScrutinizer.java, line 105. This is slightly more flexible for the user. I would recommend doing this in RMIR too.

I cannot get this to work in RMIR. My Java version is 14.0.2, which accepts scaling in Setup.vbs. I have added

Code: Select all

else if ( "-scaling".startsWith( parm ) )
        {
          String scale = args.get( ++i );
          scaleStr = "Setting sun.java2d.uiScale = " + scale;
          System.setProperty("sun.java2d.uiScale", scale );
        }

into the args processing in createAndShowGUI( ArrayList< String > args ) and I print scaleStr in rmaster.err to confirm the setting, thus

Code: Select all

Setting sun.java2d.uiScale = 3
RMIR v3.0.16
Installation folder is not read-only
Incorporates Girr v2.2.13
Girr Commit Id: 60ed266
Incorporates IrpTransmogrifier v1.2.13
IrpTransmogrifier Commit Id: f929635
System Properties:
   java.version = 14.0.2

The scale factor is not acted upon. What am I doing wrong?

[Barf]

For technical reasons, I am not able to give a detailed answer until tomorrow(?), but I suspect that the setting of the parameter comes too late, after the GUI is already initialized.

Have you considered using JCommander for decoding the command line parameters? See IrScrutinizer.java for an example.

[Barf]

For technical reasons, I am not able to give a detailed answer until tomorrow(?)

The "technical reasons" are fixed (my Linux main computer had to be reinstalled (btrfs corrupt)). Sorry for not replying earlier. I was fairly convinced that my assumption ("too late") was correct, so I did not investigate further.

I tried with different locations for the setProperty statement, but I could not get it to work. I spend around one hour, and could not find anything that worked. It is a mystery for me that it works in IrScrutinizer but not in RMIR/RemoteMaster.

Looking forward to a response to

Have you considered using JCommander for decoding the command line parameters? See IrScrutinizer.java for an example.

Main advantage would be that the code will be easier to read, maintain and extend.

[mathdon]

I have now posted development build RMIR v3.0.16 in the RMIR Development folder on SourceForge. This build adds a new menu item "File > Summary > Create RDF Info File" that creates a CSV file of extracts from all RDFs. This is intended to be used to create the Wiki Remote Guide of remotes supported in the current release of Remote Master. The build also fixes an issue with Ring Color in the Device Button table for URC-7935 Streamer remote. The Streamer device is the only one whose ring color is editable, but previous releases have allowed you to apparently edit the color for other devices, though the edits were not effective. An attempt to edit a color that is non-editable now displays an information message.

[mathdon]

I have now posted development build RMIR v3.0.17 in the RMIR Development folder on SourceForge. In addition to the changes in development build v3.0.16 reported above, this fixes an obscure bug in creating a new Activity for XSight Touch and related remotes. It also changes the processor for Comcast URC-1067 (signature CS301009) from SST back to HCS08 to fix an inadvertent error in a previous release, and amends the command translator for the Bose protocol from msb to lsb.

[mathdon]

I recently discovered that it is possible to give the Dsun.java2d.uiScale spell in the program, before constructing the GUI, so that the scaling parameter can be given as argument to the program, not the JVM. This is implemented in IrScrutinizer since late December last year, see IrScrutinizer.java, line 105. This is slightly more flexible for the user. I would recommend doing this in RMIR too.

Earlier I replied to this to say that I could not get it to work in RMIR, to which you responded

I tried with different locations for the setProperty statement, but I could not get it to work. I spend around one hour, and could not find anything that worked. It is a mystery for me that it works in IrScrutinizer but not in RMIR/RemoteMaster.

I have now finally got this to work for RMIR. It involved significant restructuring as well as the use of JCommander, as you suggested. I need to do more testing, but intend to release this as RMIR v3.1.0 shortly.

[Barf]

Happy to hear that!

[The Robman]

Hi Graham,
One difference that I've noticed between when RMIR uses DecodeIR and the IrpTransMogy one is that the latter always returned a sub-device for NEC signals, even when one isn't needed, and this can lead to some confusion.

Bark explained what's needed here:
http://www.hifi-remote.com/forums/viewt ... 963#148963

[mathdon]

@Rob
What Barf says about the NEC subdevice issue is:

In IrScrutinizer, this parameter is available to the user as Options -> Remove defaulted parameters in decode (with the opposite meaning), In RMIR it appers to be set to "keep". This can either be changed to "remove", or the parameter can be made accessible to the user, as in IrScrutinizer.

It is set to "keep" in RMIR for a reason. I can't now recall what that reason was, but I know it caused trouble in RMIR when left as "remove". I can make it accessible to the user as in IrScrutinizer if you wish, but would not want to make it "remove" by default because of the issue that led me to set it to "keep". How big a problem do you think it is to have the subdevice display when its value is the default (i.e. complement)?

[The Robman]

How big a problem do you think it is to have the sub-device display when its value is the default (i.e. complement)?

For the average user it probably doesn't make much of a difference, they just may end up creating upgrades with sub-devices when they're not needed, and load them to the file section.

I will trip me up though when I'm investigating stuff. For example, in the thread in question, someone posted learns of a specific Toshiba remote, and as I had the decoder set to the TransMogy version, I saw a sub-device, so I checked my master files and concluded that we'd never seen that device/sub-device combination before, whereas in fact, we have many upgrades with that device code with no sub-device code.

Personally, I believe this shouldn't be controlled by an input parameter. If the NEC sub-device is the complement of the device code, it means there isn't a sub-device, so there shouldn't be a parameter where you can request that the program mis-represent the data. I believe the program should test for this and only display a sub-device when necessary, just like how we only display OBC2 for NEC-f16 signals, if OBC2 is the complement of OBC1, we call it NEC.