I’ve been using raspbmc for some time now on a RPi Mobel B and just updated last week to the first release candidate of OSMC on a new RPi 2.
I’ve always experienced that keypresses on the remote somehwo get “messy” when the CPU load rises. This means that when watching large videos (high bitrate etc) multiple subsequent keypress events (forward, backward etc) just get “swallowed”.
Those “swallowed” keypress events aren’t shown in the log when running the command tail -F /home/osmc/.osmc/temp/osmc.log | grep OnKey
Some more info:
This does not happen as long as I’m in the menus or if the video is of lower bitrate/size (no problem with repeat filters).
Also if I use the android remote control app YATSE, the Pi is fully responsive, even on large videos which IMHO indicates that it’s no basic performance problem of the Pi or OSMC itself…
My remote is a One for All URC 7960 and is connected via a cheap IR module on the GPIO pins
Overall I’m pretty satisfied with the performance and don’t experience any “performance break-downs”. Neither on the Pi B, nor on the Pi 2…
I sincerely hoped that upgrading to a Pi 2 would have solved this issue for me because of the higher overall performance but unfortunately it didn’t make any difference at all.
Please let me know if I can provide any more helpful details (logs etc) since I’d really like to see this improved…
We are aware of an issue where GPIO based remotes can get unreliable during heavy network activity.
The issue is the USB/network does quite a lot of work in the kernel with interrupts disabled,
and that means GPIO interrupts get handled late, which stops the IR codes from being detected correctly.
We do have a plan to force the USB handling to occur on a different core to the other interrupts, which should solve the issue. I’ll report here when this is ready.
I can’t say I’ve ever noticed lost remote clicks under load via GPIO IR receiver.
Via remote controls/keyboards connected to USB, yes (this is a limitation of the USB controller and USB drivers on the Pi which can experience lost USB packets under high loads) but not via GPIO or CEC for that matter.
What happens if you monitor the output of lircd with irw over ssh ? Like this:
irw /var/run/lirc/lircd-lirc0
Any lost events there ? Also what about if you monitor the output after eventlircd ? Like this:
irw /var/run/lirc/lircd
For a GPIO IR receiver the signal goes from the lirc_rpi kernel module to lircd via /dev/lirc0, then via uinput to eventlircd, finally from eventlircd to kodi via the lirc socket at /var/run/lirc/lircd, so there are a number of steps in the path where problems could potentially occur.
@DBMandrake I haven’t monitored with the commands you gave, but am going to as soon as I can and report back here even if it could take some days…
@popcornmix That’s good to here and sounds really promising! Thanks for the information, I’m really looking forward to hearing about updates on the issue. Is there any other place where I can follow changes regarding the issue like a issue tracker or a public repository?
Any Update on this?
I currently have version 2017.10-1 installed on my Raspberry Pi 3. This Issue is driving me crazy!
I’ve tried LibrElec too and it’s the same.
Seems the raspberrypi/linux contributor isn’t motivated to solve this.
This command changes kodi’s behavior: after a remote keypress, the signal is repeated endlessly afterwards. F.e. in a movie list a KEY_DOWN scrolles endlessly to the bottom. Same behavior for high CPU and normal use.