Tki2000

OK. Thanks. Please, keep me informed.

Ok. Just I'd like to point one thing. When I get double keypresses, I only have active the WMC profile, and no keys recorded, so they do not interact. I have several other profiles active, that's true, but no keys recorded. Maybe they are interacting between themselves? Have to check it. Will post results. As you asked for my config, I leave you some testing configs: 1.-WMC_and_clear_configuration.fcfg (Just the default FLIRC configuration after a format. I get double keypresses with this). 2.-WMC_and_recorded cursors_once_configuration.fcfg (As above, but with cursor keys recorded once. I get double keypresses aswell) 3.-No-WMC_and_recorded cursors_twice_configuration.fcfg (No WMC profile active, and cursor keys recorded twice. I get single keypresses and I feel a total control response, as it should) With a hex editor, I can see several identical recording hashes between sessions. It is a good decoding routine the one you have :-) Just another thing. I can get single keypresses with a clear configuration, if I "hit" the button on the remote, instead of pressing. And I mean "hit", in the same sense a chamaeleon fires its tongue and presses the button. I think you get the idea, but it is really impractical for a human, to control something at such speed. I hope that helps. Edit: Just tested the profiles. With only Microsoft WMC Profile active, I keep having double keypresses. FLIRC Configs.zip

Hello @jason I get the MCE protocol issue. It is true, that sometimes you need two erase cycles, to actually delete a recorded key. I have been trying some of your advices and found this: Disabled Microsoft WMC Profile (as it is called in this version), so the predefined keys in this profile are not responding. I then record the cursor keys from remote, in the full keyboard layout. Things get worse. I have to double keypress cursor keys on remote most of time, to make flirc react. It does not make any difference if I keep the button pressed when recording, as suggested, to record the key repetition delay. I have to press twice the cursor up, for example, to make flirc show the cursor up key in green in the GUI, and of course it doesn't react either in KODI, until I press it twice. I have tried several erase/record cycles, to see if something went wrong when recording. Then, while in a recording session, I noticed that one of the cursors reacted at every keypress while, the others only every twice (very odd). I then took onto account, that if you have to erase the keys twice, sometimes, then the keys must have a toggling code, to make the receiver know when you have pressed a key, and you are still pressing it, or you have pressed it again, as the code will change with every new press. So in fact, every key on remote have two different key codes, and I am learning just one code for every key. Put that in practice, and learn twice every keypress. In fact, the flirc application lets you learn the new "duplicated" code, without taking notice it was from the same key, because it really has different codes. Now it reacts at every remote keypress. The bad thing is that every key, occupies double the space in flirc flash memory. Now I have a way of recording keys from this remote, and make it work properly, but I consider it a patch. Another thing is that when I activate the Microsoft WMC profile, the keys react at every keypress, so it is recognizing the keypresses correctly, but it incorrectly is making two key presses on PC. If an interkey_delay option is implemented (or another delay option), then this should not happen. I don't know what king of MCU the flirc v2 has, and I don't know if you can put the mcu to sleep for a given time, if you have to respond to USB messages, but it could be implemented just as a counter. When a PC keypressed has been done, start the counter/timer. If the next keypress is to be processed and the counter has not reached 0, then ignore it. When counter reaches 0, then discard que message queue to discard double keypresses. Or just discard the command, if there's any, if the counter/timer is not 0, whatever will consume less mcu cycles. On a remote you should not be pressing too quickly the buttons (in milliseconds time), so you can freely discard the too fast keypresses, or keep the same processing as now, if interkey_delay (or delay option) is 0. That's an option that could make compatibility with remotes increase. Apart from that issue. I take onto account the cross platform compatibility, the flirc has, for the programming tool. To make the flirc_util know when the GUI is opened, I may suggest what I do when I work with PLCs, and need exclusive access with only one application. I put a lock on PLC, that is on, when the first application is running, and will clear when application is shut down. All application that needs access to PLC, first read the lock. If it is on, then they will deny any action, and inform the user. I need another tool, to force the lock to clear, just in case the locking application will not work (crash or not present anymore). You may use a var in flirc hardware, to make the lock, and use GUI to put/clear the lock when flirc is detected, and implement the "force clear lock" option in flirc_util, just in case the GUI has crashed. Check the lock in flirc_util before taking any action over flirc hardware, and inform the user that the GUI is running. It should be cross platform wise. Thank you for your work and response.

Some suggestions to make more script friendly, or just to improve security or missing things. flirc_util options: - format : does not asks for confirmation. It is dangerous. Any "delete all" action should ask for confirmation, if not overridden by a force switch. - keys : does not show which HID code is tied to the key index, if it is not recognized by the default listed keys (it always shows !). It should be anyhow a good practice to show the HID code used, even if the key is recognized. Perhaps by inserting a new column between "ID" and "key" columns, as the "key" column is of variable length and should be the last one. If this is to be implemented, then it would allow to "delete_index" the index bound to the shown HID code, when delete_index would have been fixed (it is not working right now). Scripts could retrieve the list of indexes bound to HID codes that way, and act properly. It should be a good idea, to have a "play_index" or "trigger_index" option, to emulate any recorded key in a script. That way, it should be possible to play a manually recorded special HID code (with record_api), and see if it works as it should, in any application that is receiving that special HID code. And everything without the remote. Keyboard layouts in GUI, do not allow for any special HID codes to be recorded (as numpad keys, for example). So you can emulate a numpad without a numpad in scripting. Inhibit the triggering of the newly recorded key, for, let's say, 1 second (put the FLIRC to sleep?). That way the computer may not sleep itself, just after recording the sleep command, which is annoying. And helps avoiding any side effects, by triggering the key, in the "recording environment" (Alt+F4 should be annoying too, in a Windows environment, as it closes the window). May be it is a side effect, as interkey_delay is not working, and I get lots of double keypresses with FLIRC. Keep the good work going on. It really is very valuable.

I think this piece of hardware is very useful, and has a very good work behind, but today you're going to hate me a little more :-) I found some bugs in version 3.0.29 aswell in version 3.1.0 (using Windows) I have some suggestions too, to try to improve the behaviour of this little device. I will put them on the appropiate thread, later. flirc_util.exe bugs. Tested versions: flirc_util version v3.0.29 [v3.0.29] Firmware: v4.2.2 [0x5384F860] flirc_util version v3.1.0 [v3.1.0] Firmware: v4.2.2 [0x5384F860] - delete_index : does not work at all. It does not delete any command indexes shown by option "keys" or "settings". - record_api : does not work when GUI is running. It should detect it, or at least when it errors, tell the user to check if GUI is running. - interkey_delay : make it work, please. More than 50%, i get double keypresses when using my remote (Philips MCE remote). It is very irritating to navigate through folders in KODI, as it enters and exits with just one press. It exits too, just by selecting the shutdown menu, as the exit option is the first one, and it selects it when entering the menu. Navigating through options, jumps 2 options most of the time. It is very frustating. After sending a key press, FLIRC should pause for a given time, before sending again the same keypress, and it should be driven by interkey_delay option. Implementation on GUI should be valuable too. At some point, any commands used with flirc_util.exe fail if GUI is running. Is there a way of detecting if GUI is running, and telling the user that condition? GUI bugs. Tested versions: GUI 3.0.29 GUI 3.1.0 - Cannot delete any key from remote. GUI says the key is deleted, but it cannot be reassigned, it flashes when pressed on remote, and "flirc_util.exe keys" shows it as still present. Is the GUI using the "delete_index" action? If so, it may explain, that behaviour, as delete_index is broken. Only way of deleting a key is formatting device (Clear in GUI), so everything is lost, or using commandline "flirc_util.exe delete" which is working (but delete_index is not). - GUI keeps telling that version 3.1.0 is newer than 3.1.0 and offers to download the "new" version. It should say that you're up to date. I'm trying to explain the bugs as detailed as I can. If you need some more input, please tell.

Thank you.

Flirc has just updated GUI for Windows to version 3.1.0 in web. Downloaded and installed, and the GUI when running is 3.0.29. If checked via web for updates, it finds 3.1.0 and updates again. It downloads and installs, and the GUI keeps on 3.0.29, so it keeps saying that there's a new version (3.1.0), again, and again, and again...