I’ve been having an issue with my Logitech Harmony One IR remote repeating commands for a while (ever since the May update), but I haven’t had time to troubleshoot it, so I wanted to post here to see if it was a known issue with a known resolution before I started trying to debug. I didn’t see anything in searching the forums, but sometimes I just don’t use the right terms, so if I missed an existing thread, please point me in that direction.
My Harmony One remote worked normally with the Vero 4K+ from the time I got it up until the May update, but after the May update (and continuing with the June update), any command it tries to issue gets repeated about 100 times by the Vero (e.g., if I hit the down arrow, it will spend the next minute trying to go down in menus). The OSMC RF remote still works perfectly, so I’ve just fallen back to using that for the time being, but I was wondering if some default sensitivity setting for the IR receiver got changed in the May patch that I could swap back in a config file, or something else along those lines.
Has anyone else experienced this issue, and, if so, did you find a resolution?
EDIT: I happened to update to the May build on the same day I moved a wireless access point near the Vero due to remodeling work we’re performing on our house. The issue was the proximity of the access point, and had nothing to do with the May update. See this post for more details:
My remote is one of the older models that only supports IR; it predates the Bluetooth Harmony line.
EDIT: For reference, I tried the usual changes within the Harmony remote software to decrease the length of the IR signal being sent, but that only led to it occasionally missing the command entirely, while still repeating a bunch of times when it did register the command.
Are you using the external IR receiver dongle ? If not, give it a try as it performs better than the built in sensor which shares the same IR window as the power LED.
Make sure it’s plugged into the correct port on the rear as the IR receiver port and headphone socket are side by side. I don’t remember off hand which one is which but you can check you are using the right one by pointing your remote at the remote receiver and covering the front of the Vero4k to block the built in sensor - if it still works you must have the right socket.
Is the IR receiver (whether built in sensor or the remote IR sensor) behind frosted glass or out in the open ? Is it subject to direct sunlight ?
One other thing to check is that some types of LED lighting can cause interference with sensitive IR receivers. Do you only have a problem with artificial lighting turned on in the room ?
Some changes were made to the way repeats are filtered out in the May update, however it’s likely that the changes are exposing an underlying problem with your IR reception as the repeat delay was unreasonably long before the update and would tend to hide intermittent IR reception issues.
I just checked and it looks like I’m using the Media Center PC > OSMC > Vero 4K profile. Is that the right one to be using? Since it was working fine prior to the update, I had assumed I landed on the appropriate profile.
Was that supposed to come with the Vero 4K+? The only dongle that came in my box was the USB RF receiver for the OSMC remote.
It’s completely out in the open, and I’m using it at night in a blacked out room (no sunlight, no artificial lighting). Moving closer or further away from the unit while attempting to use the remote also has no effect.
Are the changes hardcoded into the kernel, or is there a setting I could modify to experiment with different sensitivities for troubleshooting purposes?
A good profile to use, provided you don’t have an Xbox 360 in the house, is the Xbox 360 media remote profile, as it has a lot more buttons mapped than the regular OSMC remote control.
Also as it uses the RC6 protocol it will work more reliably on a Vero4K than a remote using the RC5 protocol that the original white OSMC remote used that your harmony profile will be based on.
Thinking about it a little more you may be experiencing a problem we discovered where RC5 protocol remotes are not decoded very reliably using userspace lircd on the Vero4k. (But can be reliably decoded using the kernel mode RC5 decoder configured with ir-keytable)
In the long term we will be migrating from lircd to kernel decoders configured using ir-keytable (since lircd is being deprecated in Linux) but this is a lot of work and won’t be completed in the near future.
Assuming you are affected by this issue (and we’re not sure yet) then your choices to get it working reliably are to either set up and use ir-keytable mappings for the remote yourself, (we don’t have any specific documentation for how to do this, and you would need to create the configuration file yourself) or switch to a remote profile that doesn’t use RC5.
I’d recommend giving the Xbox 360 profile a try if you can as I know that one works well.
Yes I believe the Vero4k+ came with the remote IR receiver as well, it has a plug on the end that looks like a headphone jack. @sam_nazarko can advise whether you should have got one.
They’re not hard coded in the kernel however there were two changes made. I’m not sure how technical you are but these are the changes made:
A udev rule was added which uses ir-keytable to set the repeat delay of lircd based remotes (bottom section) and all other remotes. (Middle section) You could adjust the delay which is currently set to 700ms and then reboot for it to take effect, however 700ms is already quite long.
Hmm… perhaps I just didn’t see it in the box. Let me see if I can track down the box among my electronics boxes in the basement and double check.
Just tried switching the Harmony and OSMC over to using the Xbox 360 profile, and, unfortunately, the behavior is identical to using the OSMC remote profile. That would seem to rule out an RC5 vs RC6 decoding issue being the cause, correct? I also tried extending the repeat delay to a ludicrous three seconds and re-establishing the eventlircd.service repeat filter, but neither seemed to have a meaningful impact on the problem, so it seems like perhaps we’re barking up the wrong tree here. Did anything else change relating to remotes in the May update?
Given this additional information, do you still think manually constructing an ir-keytable mappings config file might resolve the issue? If so, I could try to read up on how those are constructed and attempt to put something together, although remotes/IR are definitely not my traditional coding arena.
I couldn’t for the life of me seem to get the Harmony remote working in lirc on the current OSMC/Debian version. No matter what changes I made to the settings, an irw log was showing 100+ inputs on each button press, sometimes 1000+, basically along these lines (truncated to 32 lines for sample):
Surrendering that approach, I killed the lirc process, enabled RC5/RC6 protocols in ir-keytable and ran some quick tests, which showed the appropriate single response to each button press:
1563948648.675023: event type EV_MSC(0x04): scancode = 0x211
1563948648.675023: event type EV_SYN(0x00).
1563948651.031034: event type EV_MSC(0x04): scancode = 0x215
1563948651.031034: event type EV_SYN(0x00).
1563948652.340911: event type EV_MSC(0x04): scancode = 0x213
1563948652.340911: event type EV_SYN(0x00).
1563948653.794524: event type EV_MSC(0x04): scancode = 0x212
1563948653.794524: event type EV_SYN(0x00).
With that confirmed, I went ahead and built a custom ir-keytable mapping for the generic OSMC remote, then tested it and it appears to be working fine as far as the raw input goes:
1563950871.591432: event type EV_MSC(0x04): scancode = 0x213
1563950871.591432: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
1563950871.591432: event type EV_SYN(0x00).
1563950871.834471: event type EV_KEY(0x01) key_up: KEY_DOWN(0x006c)
1563950871.834471: event type EV_SYN(0x00).
1563950873.844160: event type EV_MSC(0x04): scancode = 0x213
1563950873.844160: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
1563950873.844160: event type EV_SYN(0x00).
1563950874.084537: event type EV_KEY(0x01) key_up: KEY_DOWN(0x006c)
1563950874.084537: event type EV_SYN(0x00).
1563950875.654616: event type EV_MSC(0x04): scancode = 0x212
1563950875.654616: event type EV_KEY(0x01) key_down: KEY_RIGHT(0x006a)
1563950875.654616: event type EV_SYN(0x00).
1563950875.904479: event type EV_KEY(0x01) key_up: KEY_RIGHT(0x006a)
1563950875.904479: event type EV_SYN(0x00).
1563950876.917842: event type EV_MSC(0x04): scancode = 0x211
1563950876.917842: event type EV_KEY(0x01) key_down: KEY_UP(0x0067)
1563950876.917842: event type EV_SYN(0x00).
1563950877.164463: event type EV_KEY(0x01) key_up: KEY_UP(0x0067)
1563950877.164463: event type EV_SYN(0x00).
1563950877.940184: event type EV_MSC(0x04): scancode = 0x215
1563950877.940184: event type EV_KEY(0x01) key_down: KEY_LEFT(0x0069)
1563950877.940184: event type EV_SYN(0x00).
1563950878.184515: event type EV_KEY(0x01) key_up: KEY_LEFT(0x0069)
1563950878.184515: event type EV_SYN(0x00).
I switched the remote profile within OSMC to some random remote that didn’t have overlap with those scancodes, then restarted the lirc process, and tested the remote once more, whereupon everything seemed to be working as expected. One button press on the remote resulted in one response from OSMC. (Huzzah!)
Now that I’ve confirmed the bug is with lirc and that ir-keytables works fine, how should I optimally configure OSMC to utilize the custom ir-keytable? I’m not familiar enough with the code paths for remote handling to make even an educated guess on that front.
I was hoping to be able to avoid using lirc entirely, since it seems to be the source of whatever the problem is, but I found that even with ir-keytable correctly configured, the lirc service has to be running for the codes from my custom config to be registered in Kodi/OSMC (at least when I’m just loading them in via the -w parameter in ir-keytable). I’m assuming that’s because some layer of the keymapping is currently being handled in lirc? Is there a way I can route around that and map straight from ir-keytable to Kodi/OSMC (or is there something I’m currently doing wrong that’s prohibiting it from doing so automatically)?
Eventually, we’d like to ditch LIRC and do processing of remote events entirely in the kernel; using a systemd service to load the remote profile on boot.
We have a couple of issues however:
We’ll need to build up another base of remote profiles in an ir-keytable compatible format
We need to do this with the next version of My OSMC; My OSMC 2.0.
Is there a way to do this manually with the current version of OSMC? I’m happy to set up some overrides on my end if that would allow me to achieve this functionality for the time being. What specifically is needed for OSMC to process the requests directly without LIRC running, assuming ir-keytable already has the appropriate table loaded?
It just occurred to me that Kodi might cache some remote factors on startup. Do I need to be restarting the Kodi service after loading the key table for it to function directly?
I’ve moved to ir-keytable with OSMC on my Vero 4K+ units and am not seeing any repeats now with my harmony remotes. Here’s the instructions for replicating what I did:
I’ve just done some testing on my Vero4k+ with an actual Xbox 360 remote using the regular lircd xbox 360 profile.
With Wi-Fi connected but mostly idle the remote is a bit less responsive and sometimes exhibits unwanted repeats. If I transfer data over Wi-Fi at the same time (I installed the speedtest-cli debian package and ran ‘speedtest’ via ssh) then the remote becomes completely unusable and will either not respond or generates infinite repeats.
On Ethernet with Wi-Fi turned off completely it works perfectly - responsive, no random repeats etc even when running speedtest to generate network traffic.
Using ir-keytable I don’t see any issues with the remote when using Wi-Fi.
So it appears there is some sort of conflict between the Wi-Fi driver and userspace Lircd.
If you are using Wi-Fi, could you try generating a lot of wifi traffic while testing the remote as I did above and confirm whether this makes your remote much worse.
And if possible could you try turning off WiFi and temporarily use an Ethernet connection to see if the remote works normally even with the Lircd profile when data is being transferred ?
My Vero is already hardwired, so unfortunately it doesn’t seem likely that wi-fi is a factor in my case. The addition of the gigabit ethernet port on the 4K+ was actually what finally convinced me to give it a try, since I dislike using wi-fi for anything that requires meaningful stability or bandwidth.
That said, I don’t remember if wi-fi is disabled outright on the Vero, or just unused. If the Vero was configured to use ethernet on initial setup, would it have automatically disabled wi-fi, or would I have had to make a manual configuration change after the fact?
Hmm. Do you have any additional software besides Kodi running that could be using a lot of CPU ? Do you see the problem with Kodi just at a menu, during playback or both ?
I get the same symptoms as you with Wifi activity however when I use Ethernet (which I normally do) the 360 remote is working flawlessly for me even with lircd.
I’m testing further to see if I can reproduce the symptoms with something other than WiFi activity.
The reason lircd is susceptable to this issue while kernel decoders aren’t, is that it does the measuring and decoding of the individual marks and spaces in the IR code in software in userspace code - so if lircd is starved of execution time it will cause the decoding to become unreliable, whereas the kernel decoders effectively run at a very high priority in the kernel thus measure the IR marks and spaces reliably even when the system is under heavy load.
I can reproduce the problem with WiFi activity but there may be other types of system load that can cause it.
I think WiFi defaults to disabled unless you enable it, however it would be a good idea to check that it’s actually disabled and not just disconnected from any AP’s.
Have you found the remote IR receiver yet ? If so give that a try just in case the built in IR sensor in your unit has a fault.
Everything on my Vero is completely stock. No add-ons, no additional software or anything else.
The issue occurs everywhere for me. On the menus, I would get pinned to the top or bottom by clicking an arrow once, but the factor that finally convinced me to sort out the issue is that I would occasionally grab the Harmony remote when I needed to quickly pause what I was watching, and the result would be a slideshow for the next several minutes (from play/pause commands being buffered).
Unfortunately, we’ve been doing some remodeling this month, so my basement is currently overloaded with furniture and other materials that normally reside in other rooms of the house, and tracking down items requires a little more work than usual. I haven’t had the time to chase it down yet, but as soon as I get a chance to do so (or next month after the work is finished we can restore everything to its rightful place), I’ll try to hook it up and report back.
There is a wireless access point in the room with the Vero. I’ll see if I can find some time in the next week where it wouldn’t inconvenience other family members too much to kill the wi-fi for a short time to run some tests. Is there any reason the impact wi-fi has on the lirc processing would have changed with the May update, though?