Jump to content
Flirc Forums
Tki2000

Bugs in 3.1.0

Recommended Posts

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.

Share this post


Link to post
Share on other sites
6 hours ago, Tki2000 said:

- delete_index : does not work at all. It does not delete any command indexes shown by option "keys" or "settings".

I can confirm that.

6 hours ago, Tki2000 said:

- 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.

I don't think that's a bug, but I agree that there could be some kind of warning about the GUI. Maybe in the help message or when any error is reported. As for the actual detection of the GUI being opened, I don't know if there's an easy way to check that in a cross-platform way (remember that this would need to work across all supported systems). Maybe some locking mechanism could be used.

6 hours ago, Tki2000 said:

- 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.

Flirc v2 doesn't support the interkey delay setting because it actually learns the interkey delay from the remote itself and stores it for each recorded key. For that to work properly you need to actually hold the button when recording (so the signal has a chance to repeat itself) not just press it quickly.

6 hours ago, Tki2000 said:

- 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).

I can't reproduce this. At least not on Linux. Please remember that the MCE remote is using RC5 protocol with two separate signals for each key. You need to erase it twice in the same way you record it. The Erase button in GUI uses the same procedure as the delete command in the flirc_util.

6 hours ago, Tki2000 said:

- 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.

Sorry to hear that. I hope it'll get sorted out as soon as possible. @jason?

 

Share this post


Link to post
Share on other sites
1 hour ago, yawor said:

I can confirm that.

I don't think that's a bug, but I agree that there could be some kind of warning about the GUI. Maybe in the help message or when any error is reported. As for the actual detection of the GUI being opened, I don't know if there's an easy way to check that in a cross-platform way (remember that this would need to work across all supported systems). Maybe some locking mechanism could be used.

Flirc v2 doesn't support the interkey delay setting because it actually learns the interkey delay from the remote itself and stores it for each recorded key. For that to work properly you need to actually hold the button when recording (so the signal has a chance to repeat itself) not just press it quickly.

I can't reproduce this. At least not on Linux. Please remember that the MCE remote is using RC5 protocol with two separate signals for each key. You need to erase it twice in the same way you record it. The Erase button in GUI uses the same procedure as the delete command in the flirc_util.

Sorry to hear that. I hope it'll get sorted out as soon as possible. @jason?

 

Version issue should be fixed. If you update to the latest. 

@yawor is correct, I believe it's an MCE issue. Go to advanced, and disable the Windows MCE profile, see if that helps the keys being 'too' sensitive. Please let me know if that works.

Share this post


Link to post
Share on other sites
On 10/17/2017 at 5:24 PM, jason said:

Version issue should be fixed. If you update to the latest. 

@yawor is correct, I believe it's an MCE issue. Go to advanced, and disable the Windows MCE profile, see if that helps the keys being 'too' sensitive. Please let me know if that works.

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.

Edited by Tki2000

Share this post


Link to post
Share on other sites

With WMC (or any other RC5/RC6 protocol remote) you always need to record the key twice. There's no other way as Flirc is not a dedicated WMC receiver. It does not decode the protocol and retrieve the command. For Flirc to work universally with most of the remotes (not only WMC) it uses a proprietary algorithm which calculates a hash from a signal timing information. Changing even a single bit (the RC5/RC6 toggle bit) changes the timings and the hash is different. So to Flirc each key press is actually a totally different button on the remote.

When you have built-in profiles enabled and you only record the key once, it interferes with the built-in table 

With WMC you have following choices:

  • Don't record buttons that are already supported by the built-in WMC profile (like direction keys)
  • If you record some of them, always record them twice with the same key selected in the GUI or flirc_util (may cause issues if you forget to record some key twice)
  • Disable the WMC built-in profile and record all keys you want in the way you want (recording twice is still a requirement)

Can you record a key from your WMC remote and attach the config file? I want to check something. Be sure to hold the key while recording.

Share this post


Link to post
Share on other sites
22 hours ago, yawor said:

With WMC (or any other RC5/RC6 protocol remote) you always need to record the key twice. There's no other way as Flirc is not a dedicated WMC receiver. It does not decode the protocol and retrieve the command. For Flirc to work universally with most of the remotes (not only WMC) it uses a proprietary algorithm which calculates a hash from a signal timing information. Changing even a single bit (the RC5/RC6 toggle bit) changes the timings and the hash is different. So to Flirc each key press is actually a totally different button on the remote.

When you have built-in profiles enabled and you only record the key once, it interferes with the built-in table 

With WMC you have following choices:

  • Don't record buttons that are already supported by the built-in WMC profile (like direction keys)
  • If you record some of them, always record them twice with the same key selected in the GUI or flirc_util (may cause issues if you forget to record some key twice)
  • Disable the WMC built-in profile and record all keys you want in the way you want (recording twice is still a requirement)

Can you record a key from your WMC remote and attach the config file? I want to check something. Be sure to hold the key while recording.

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

Edited by Tki2000

Share this post


Link to post
Share on other sites

Yeah so to be clear. Disable the WMC profile and record your keys manually. Record each key twice. For example. Record up. The. Record up again. 

That’ll fix it. 

We we know what the issue is and Yawor and I are discussing solutions. 

Share this post


Link to post
Share on other sites
2 hours ago, jason said:

Yeah so to be clear. Disable the WMC profile and record your keys manually. Record each key twice. For example. Record up. The. Record up again. 

That’ll fix it. 

We we know what the issue is and Yawor and I are discussing solutions. 

OK. Thanks.

Please, keep me informed.

Share this post


Link to post
Share on other sites

I'm excited about this new version of Flirc (3.1.0) -- I had version 1.x the past year and no idea there were any updates. :)

 

But the new high-res window is too large and it can't be resized, making it harder to use. I'm running Flirc on my home-theater system, a standard HD 1920x1080 display. The bottom of the Flirc UI is cut off and I can't get it on the screen!

I've attached a screenshot to illustrate.

 

Flirc on HD.PNG

Edited by ShoutingMan

Share this post


Link to post
Share on other sites

Have you changed your scaling settings in Windows graphics or desktop settings? The GUI shouldn't be bigger than about 800x600. Exact size depends on the OS it's running on. It shouldn't be that big for sure.

Share this post


Link to post
Share on other sites
4 hours ago, yawor said:

Have you changed your scaling settings in Windows graphics or desktop settings? The GUI shouldn't be bigger than about 800x600. Exact size depends on the OS it's running on. It shouldn't be that big for sure.

Yep, that's it. I run the Windows at 150% scaling for usability for "couch" viewing on a large screen HD display. I can flip back to 100% and run Flirc as needed.

Share this post


Link to post
Share on other sites

nice call @yawor. I was pretty upset thinking I needed to keep looking at this. This was on my list for a while and required the migration to qt 5.x.

I'll put this in the documentation.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×