Best place to report bugs and improvement request is here; also available from IrScrutinizer Help -> issues. It requires GitHub registration. But it is also OK to report bugs here, or on RemoteCentral.
I made an issue of your report.
Thank you for the bug report. The bug will be fixed shortly.
IrScrutinizer: capturing, generating, analyzing, import, exp
Moderator: Moderators
Should be fixed now. Fix available in the daily build. Please verify that it is working for you.
The current official release 2.4.0 is over a year old. Time for a new release!
IrScrutinizer 2.4.1 has been released, available for download here.
This release contains a number of semi-important bug fixes and enhancements. Everyone is encouraged to update.
Release notes:
IrScrutinizer 2.4.1 has been released, available for download here.
This release contains a number of semi-important bug fixes and enhancements. Everyone is encouraged to update.
Release notes:
Code: Select all
The notation #n refers to issues number n at
https://github.com/bengtmartensson/IrScrutinizer/issues
==============================================================================
Version 2.4.1, released 2024-03-16.
* Use IrpTransmogrifier 1.2.14, Girr 2.2.14, Jirc 2.2.14, RemoteLocator 0.x.y, HarcHardware 2.4.1.
* Bugfix: Helptext links failed if the IrpProtocols pathname contained spaces.
* Remove option "Reject Lirc imports without timing". Resolves #522.
* Implemented secondary export formats file/directory. Resolves #294.
* Bugfix for files located within the directory applicationHome.
* Installation message windows (post_install.txt) update.
* Fix bug in Ctrl-F handling in tables. #387.
* Implemented secondary IrpProtocols file. #294.
* IrPlotter: improved mouse-based zooming. Resolves #361.
* Minor tweaks in IrPlotter: Fix glitch in plot scales, leading to overlapping text. #291.
* Remove GlobalCache IR database (old) importer. #516.
* Parametric and raw remote table now has search. #387.
* Say "delete", not "clear" on signals on some popup menus.
* Update the embedded Java JVM on Windows. #515.
* Update Java JVM for AppImage. #514.
* Option --scale now handled in the Java code, not in a wrapper. #513.
* Allow empty commands to be imported in Girr through Options -> Import options -> Accept empty Girr commands on import. #511.
* Windows: install wrapper for HarcHardware.
* AppImage: do not include /usr/lib/rxtx and /usr/lib64/lib any more, not used anymore.
* AppImage can now invoke HarcHardware's main routine, just as IrpTransmogrifier's. #464.
* Silly case sensitivity fixed. #498.
* Export signal: check savefile for null-ness. #506.
* Robustness fix for appimages, see #498.
* Do not take frequency from GUI for signals without explicit frequency. #496.
* Two new/fixed export formats: Homeassistant Broadlink Switch and Homeassistant Broadlink remote. #477.
* New export format Homeassistant ITach (GlobalCache). Resolves #478.
* Fixes to Broadlink*formatter, to accomplish to RF support.
* Fix incorrect propertly name with lirc config (Thanks Bill Ryder)
* Export formats IrToy and IrToy-bin fixed. #482.
* Fix GuiMain.analyzerMaxParameterWidth for changes in IrpTransmogrifier, #234.
* Partial fix of the Homeassistant-Broadlink export format, #477.
* Added Discussions item under Help menu.
* Some Arduino export fixes. #476, #413, #444, #476
* Do not use deprecated Girr functions. #474.
* Replace minimal-json library. #473.
* Robustness fixes for export GUI.
* Delete original pronto hex in the pronto oneshot export.
* Misc Broadlink signals fixes, both hex and base64. #375, #472.
* New export format tester-arduino.
* Change she-bang of setup-irscrutinizer.sh to say /bin/bash explicitly. #470.
The current official release 2.4.1 is almost a year old. Time for a new release!
IrScrutinizer 2.4.2 has been released, available for download here.
This release contains a number of semi-important bug fixes and enhancements. Everyone is encouraged to update.
Release notes:
IrScrutinizer 2.4.2 has been released, available for download here.
This release contains a number of semi-important bug fixes and enhancements. Everyone is encouraged to update.
Release notes:
Code: Select all
Version 2.4.2, released 2025-02-17.
* Use IrpTransmogrifier 1.2.14, Girr 2.2.14, Jirc 2.2.14, RemoteLocator 1.0.0, HarcHardware 2.4.2.
* Fixes to IRremote export (several dialects). #444.
* Some URL/URI related fixes.
* New GUI option Options -> Debug -> XSLT Debug.
* Fix bug when calling DynamicRemoteSetExportFormat.main() without GUI.
* Improvements of RemoteLocatorImporter.
* Ensure that meta data in girr files on the command line are read.
* Support import and export of Flipper *.ir files.
* Fixed bug in Girr export of certain combinations of parameter inheritance and defaults. Girr #539.
* Fix bug in "duplicate" in Parametric Remote table. #544.
* Minor cleanup of documentation of export format.
* New command line option: --remotelocator.
* Fix some problems in importing Girr files with embedded IRP protocol. #542.
* GUI option for removing secondary IRP data base. Resolves #540.
* Some tweaks on icons and help texts.
* XCF import: Handle duplicated function names by renaming,
In Version 4, support pages; they now map to CommandSets. Resolves #538.
* CsvParametrizedImporter: Handle parameter value "none" more gracefully.
* Reject empty clipboards when importing remotes.
* Support import XCF version 6 import. Resolves #537.
* Reorganized baud rate setting in GirsClientBean. Resolves #534,
* Minor fix to handling of propertiesfile.
* Restructured reAnalyze/scrutinizeSignal.
* Fix decoding bug. #531.
* Relocate ControlTower "Importer" to Tools. #525.
Thank you for this tool, I recently built a small Arduino board with capture and transmit capabilities, and used it with IrScrutinizer.
I have a small feature request, if possible: to be able to send repeated signals from any tab, not only from the Hardware tab (using the Count drop-list).
Some remote control keys have different functions based on whether they are clicked or long-pressed on Samsung TVs. This is mentioned in the Samsung Developer documentation, and can also be checked by using the "Learn Remote" feature on Samsung TVs. [*]
Let's say the "Mute" key on a Samsung TV remote control: a single press on the key has the "Mute" behavior, but a long press of the key (which simply does repeats) is interpreted by the TV as the press of the AD/SUBT remote key (and opens the Accessibility Shortcuts menu of recent TVs instead of muting the sound).
The TV user manual also mentions this behavior: it says that if you "press and hold for 1 second or more the remote key" then this other behavior happens than the default one. Sometimes they even mention "if you press and hold for 3 seconds or more" - I noticed this for a combination of pressing two keys to trigger Bluetooth pairing.
I used IrScrutinizer to see what happens while sending various codes to a Samsung TV, but that meant I had to input on the Render tab the code to send, and then switch to the Hardware tab and try pressing the "Transmit rendered" button there with Count set to 1 to trigger the "short key press" behavior and with the Count value set to 10 to trigger the "long key press" ("one second or more") behavior.
It would be nicer to have the ability to send such repeats straight from the Render tab (or even the Scrutinize Signal tab as well).
[*] The "Learn Remote" feature on Samsung TVs can be accessed from the Accessibility Shortcuts menu -> Learn Remote. It will show what is the key pressed on the remote as well as offer a description for it and speak it out for you. This is how I discovered that a long press on Return is actually interpreted as pressing the Exit key, or a long press on the Mute button is interpreted as a press of the AD/SUBT. remote control key.
I have a small feature request, if possible: to be able to send repeated signals from any tab, not only from the Hardware tab (using the Count drop-list).
Some remote control keys have different functions based on whether they are clicked or long-pressed on Samsung TVs. This is mentioned in the Samsung Developer documentation, and can also be checked by using the "Learn Remote" feature on Samsung TVs. [*]
Let's say the "Mute" key on a Samsung TV remote control: a single press on the key has the "Mute" behavior, but a long press of the key (which simply does repeats) is interpreted by the TV as the press of the AD/SUBT remote key (and opens the Accessibility Shortcuts menu of recent TVs instead of muting the sound).
The TV user manual also mentions this behavior: it says that if you "press and hold for 1 second or more the remote key" then this other behavior happens than the default one. Sometimes they even mention "if you press and hold for 3 seconds or more" - I noticed this for a combination of pressing two keys to trigger Bluetooth pairing.
I used IrScrutinizer to see what happens while sending various codes to a Samsung TV, but that meant I had to input on the Render tab the code to send, and then switch to the Hardware tab and try pressing the "Transmit rendered" button there with Count set to 1 to trigger the "short key press" behavior and with the Count value set to 10 to trigger the "long key press" ("one second or more") behavior.
It would be nicer to have the ability to send such repeats straight from the Render tab (or even the Scrutinize Signal tab as well).
[*] The "Learn Remote" feature on Samsung TVs can be accessed from the Accessibility Shortcuts menu -> Learn Remote. It will show what is the key pressed on the remote as well as offer a description for it and speak it out for you. This is how I discovered that a long press on Return is actually interpreted as pressing the Exit key, or a long press on the Mute button is interpreted as a press of the AD/SUBT. remote control key.
Thank you for the suggestion. Actually, I have been thinking about something similar myself -- since I now own a Sony TV, which ignores a single send.
How things work now: The dropdown on "Hardware" is observed for all "Transmit" commands: Buttons on Scrutinize signal, Render, Hardware; Menu selection on Scrutinize remote/parameteric and raw and on Import.
Possible change: On the buttons, Left works as previously, right brings up a popup menu for the number of sends. On the menus, instead a pull-right menu allows selecting the number of sends. And a reasonable keyhelp.
How things work now: The dropdown on "Hardware" is observed for all "Transmit" commands: Buttons on Scrutinize signal, Render, Hardware; Menu selection on Scrutinize remote/parameteric and raw and on Import.
Possible change: On the buttons, Left works as previously, right brings up a popup menu for the number of sends. On the menus, instead a pull-right menu allows selecting the number of sends. And a reasonable keyhelp.
I was not aware the dropdown in the Hardware tab had such an influence on how other things worked in the other tabs. That's a hidden dependency which is not obvious, and is likely better to not have. 
It might be useful to be able to specify how many repeats to send, and not have to pick from a list of predefined options. I just discovered that some buttons on the remote trigger some menus when held for 5 seconds (Play or Play/Pause show the About This TV menu) and even 10 seconds (Info will display the Signal Information menu which otherwise would have to be raised from somewhere inside the Settings Support > Device Care > Troubleshooters page).
That would mean some sort of numerical input, one could use to type the number of repeats.
I'm not sure what would be the best location for it, as it would be useful to be able to change it without changing the tab your are currently on. That would mean... either on each tab that makes use of it, or in the tab bar itself, or maybe as a widget in a status bar.
It might be useful to be able to specify how many repeats to send, and not have to pick from a list of predefined options. I just discovered that some buttons on the remote trigger some menus when held for 5 seconds (Play or Play/Pause show the About This TV menu) and even 10 seconds (Info will display the Signal Information menu which otherwise would have to be raised from somewhere inside the Settings Support > Device Care > Troubleshooters page).
That would mean some sort of numerical input, one could use to type the number of repeats.
I'm not sure what would be the best location for it, as it would be useful to be able to change it without changing the tab your are currently on. That would mean... either on each tab that makes use of it, or in the tab bar itself, or maybe as a widget in a status bar.
Actually, I spent some time thinking of a response. It turned out that it is not that easy. For example, I wrote
As I read you latest post, I realized that your original request
Additional GUI elements have the disadvantage of making the usage look more complicated, and any added functionality must be weighted against this.
However, there is one change that I consider: Making the "count" parameter available in the Options pull down, using the predefined list. Plus some improvements to the tool tips, and possibly the documentation.
But again: thank you very much for your suggestions. They help to make the program (even
) better!
On second thought, I do not think this form of creativity is a good idea, since it breaks standard programming model of invoking actions on GUI elements, not just, for example, checking which mouse key was invoked. Being just too creative will bite back sooner or later, for example using "accessibility features".Barf wrote:On the buttons, Left works as previously, right brings up a popup menu for the number of sends.
As I read you latest post, I realized that your original request
was, at least partially, answered by the global nature of the count parameter on "Hardware", although you writestama wrote:to be able to send repeated signals from any tab, not only from the Hardware tab (using the Count drop-list).
I do not think I agree with you. "Transmit" means "transmit current signal with the parameters I have defined elsewhere", not "transmit exactly once". Although certainly improvements can be made in documentation, in particular tool tips.stama wrote:That's a hidden dependency which is not obvious, and is likely better to not have.
Additional GUI elements have the disadvantage of making the usage look more complicated, and any added functionality must be weighted against this.
The "number of numbers" is currently: 1, 2, 3, 4, 5, 6, 7, 10, 12, 15, 20, 30, 40, 50, 70, 100. It would be nice to head your argument for why this in not sufficient. Also, numericial input is clumsy from a user interface standpoint: you need to use both the mouse and the keyboard to make an entry, which is inconvenient and slow.stama wrote:It might be useful to be able to specify how many repeats to send, and not have to pick from a list of predefined options. ... That would mean some sort of numerical input, one could use to type the number of repeats.
However, there is one change that I consider: Making the "count" parameter available in the Options pull down, using the predefined list. Plus some improvements to the tool tips, and possibly the documentation.
But again: thank you very much for your suggestions. They help to make the program (even
) better!What I meant by "hidden dependency" is that it is not obvious the setting on the Hardware tab has an effect in the entire application, and is not just local to that tab. And it's not something that one may even be able to figure out - you may not realize you are sending a repeated signal instead of just a single signal while pressing "Transmit" in another tab, as usually the effect is the same.Barf wrote: As I read you latest post, I realized that your original request
was, at least partially, answered by the global nature of the count parameter on "Hardware", although you writestama wrote:to be able to send repeated signals from any tab, not only from the Hardware tab (using the Count drop-list).I do not think I agree with you. "Transmit" means "transmit current signal with the parameters I have defined elsewhere", not "transmit exactly once". Although certainly improvements can be made in documentation, in particular tool tips.stama wrote:That's a hidden dependency which is not obvious, and is likely better to not have.
I guess I got used to finding settings with a global impact located in some app-unique settings dialog, and what is located on a tab to have an impact only on how things work in that tab.
When I was trying to figure out how to trigger the "long key press" behavior for a Samsung TV remote, which is to say "press and hold for 1 second or more" according to the user manual, I had to jump from 7 to 10 as there were no values in between. "7" was still seen as a "short key press", while "10" as a "long key press".Barf wrote:The "number of numbers" is currently: 1, 2, 3, 4, 5, 6, 7, 10, 12, 15, 20, 30, 40, 50, 70, 100. It would be nice to head your argument for why this in not sufficient. Also, numericial input is clumsy from a user interface standpoint: you need to use both the mouse and the keyboard to make an entry, which is inconvenient and slow.stama wrote:It might be useful to be able to specify how many repeats to send, and not have to pick from a list of predefined options. ... That would mean some sort of numerical input, one could use to type the number of repeats.
After that, I discovered that some keys have additional behaviors if pressed for even longer than one second.
"Return" and "Play/Pause" pressed for 3 seconds trigger Bluetooth pairing.
"Play/Pause pressed for 5 seconds displays the "About This TV" panel.
"Info" pressed for 10 seconds displays the "Signal Information" panel.
I would not know what value to use for "Count" in these cases. If "Count" was a numerical input, I could experiment with different values. If it's a drop-down with a predefined list of values, my only choice is to hope some of them will match my needs.
This reminds me I should upload a .rmdu file with what I found so far.
Well, these are my thoughts on the matter, the hard part of making a choice belongs to you.