2019 April upgrade - issues (menu, Harmony bluetooth multi-keypress, CEC steal input)

mk150 · 22 April 2019 06:50

I just updated my 4K+ from the December version to the April version.

Generally everything is working okay (all videos play fine at the expected resolutions), however I have/had a few minor issues.

(self fixed) The screen resolution was set to 720p60 on first boot. I had it set to 1080p23.98. I changed this back to what I had it set at and it’s fine now.
(self fixed) The menu required a reset to defaults after upgrading, as two items in the top level menu came up as Not Found and Not Available. The menu reset fixed that. I didn’t think I customised anything in there.
(the most annoying, new bug in April not in December, not fixed) I use a Harmony Elite remote paired to my Vero 4K+. Since the April update, I’m now experiencing occasionally double inputs or input lag. What I mean by this is, when navigating the menu for example, say I’m scrolling down a list. If I press down once, I get a ‘click’ and it moves down one item. What is happening is that on a random number, either it doesn’t respond or I get multiple clicks in one go. This is not doing it fast or ‘repeat’, but rather separate, discrete button presses where I’m definitely only pressing the button once… but the Vero occasionally is now either missing it or interpreting it as more than one press. It’s mildly frustrating. I’ve tried rebooting, etc. and it won’t go away. It seems to be less bad once i’ve played a video file.
(ongoing from December build, not fixed) I still have a HDMI CEC issue where, if I enable CEC on the Vero, when I turn on my TV, receiver and another device (not the vero) the vero steals the input when coming out of standby. I have all the relevant options in the CEC settings turned off. The only way to stop this is to disable CEC on the Vero and leave it active all the time. With CEC enabled, I have it set to ‘suspend’ on TV power off. I’m not sure if this is caused by CEC being enabled, or the Vero coming out of standby and doing something at that point.

sam_nazarko · 22 April 2019 11:16

Will depend on how your remote is configured. Kodi now uses libinput to handle keyboards, and it’s possible that its repeat filter isn’t as accurate.
Would need more information and some logs to help there.

ktg1 · 22 April 2019 22:48

I have the same problem as #2. “Not Available”. Where/how do you do a menu reset?

Chillbo · 23 April 2019 06:08

Have a look at the Backup/Reset section of our skin settings under Settings/Interface/Skin/- Configure skin…

If you have customised your home menu and you don’t want to loose all of that, go to those skin settings and then under Home select Customise home menu and edit the labels of the videos and music entries.

morfei1 · 23 April 2019 06:16

The in progress TV Shows icons/poster on the mine menu are missing on both my vero4k and rpi3b+, after the April 2019 update to the v18.

I don’t have problems with the movie icons, though.

Regards!

Chillbo · 23 April 2019 07:51

Go to the above described customize home menu setting, select manage widgets for the TV show home menu entry and select Poster as the first choice of icon. This should fix it.

damianh · 23 April 2019 10:27

i’m getting the duplicate keypress issue (3) too using flirc, but no issues on the conventional keyboard (also attached). i’m on a pi3b+.

let me know if there’s any logs etc which would help.

epicwomble · 23 April 2019 11:53

Also getting duplicate button press on FLIRC.

I replaced a NUC running libreelec with a Vero4k+ the FLIRC was setup to act native to Kodi, and has worked when swapping from a Raspberry Pi 2 and 3 and then to NUC without issue.

With the vero I get the random, double press. If slow with pushing button one after another it does not get it, but if pushing many times to scroll or skip forward/back it sometimes gets double input.

let me know if need any logs.

TheDarkKnight · 23 April 2019 12:10

+1 for Vero 4K with FLIRC and seemingly random double key presses or no response when pressing a button.

damianh · 23 April 2019 17:54

i have no idea if this is any use, but here we go:

physical keyboard

2019-04-23 18:43:03.556 T:1895822048   DEBUG: CLibInputKeyboard::ProcessKey - using delay: 250ms repeat: 33ms
2019-04-23 18:43:03.556 T:1286595296   DEBUG: Thread Timer start, auto delete: false
2019-04-23 18:43:03.558 T:1916417584   DEBUG: Keyboard: scancode: 0x6c, sym: 0x0112, unicode: 0x0000, modifier: 0x0
2019-04-23 18:43:03.558 T:1916417584   DEBUG: HandleKey: down (0xf081) pressed, action is Down
2019-04-23 18:43:03.628 T:1286595296   DEBUG: Thread Timer 1286595296 terminating
2019-04-23 18:43:03.638 T:1916417584   DEBUG: Keyboard: scancode: 0x6c, sym: 0x0112, unicode: 0x0000, modifier: 0x0

occasional double-press problem from flirc remote

2019-04-23 18:43:58.126 T:1895822048   DEBUG: CLibInputKeyboard::ProcessKey - using delay: 250ms repeat: 33ms
2019-04-23 18:43:58.126 T:1286595296   DEBUG: Thread Timer start, auto delete: false
2019-04-23 18:43:58.162 T:1916417584   DEBUG: Keyboard: scancode: 0x6c, sym: 0x0112, unicode: 0x0000, modifier: 0x0
2019-04-23 18:43:58.163 T:1916417584   DEBUG: HandleKey: down (0xf081) pressed, action is Down
2019-04-23 18:43:58.382 T:1286595296   DEBUG: Thread Timer 1286595296 terminating
2019-04-23 18:43:58.407 T:1916417584   DEBUG: Keyboard: scancode: 0x6c, sym: 0x0112, unicode: 0x0000, modifier: 0x0
2019-04-23 18:43:58.407 T:1916417584   DEBUG: HandleKey: down (0xf081) pressed, action is Down
2019-04-23 18:43:58.407 T:1916417584   DEBUG: Keyboard: scancode: 0x6c, sym: 0x0112, unicode: 0x0000, modifier: 0x0

so, in both cases i get a single ProcessKey
but physical keyboard gives two scancode logs (the second is the release?)
while flirc seems to give three (auto-repeat? idk how to change the repeat rate. happy to try)

often going into menus fails, here’s a similar dump for that

physical keyboard ‘enter’

2019-04-23 18:50:20.287 T:1895822048   DEBUG: CLibInputKeyboard::ProcessKey - using delay: 250ms repeat: 33ms
2019-04-23 18:50:20.288 T:1286595296   DEBUG: Thread Timer start, auto delete: false
2019-04-23 18:50:20.307 T:1916417584   DEBUG: Keyboard: scancode: 0x1c, sym: 0x000d, unicode: 0x000d, modifier: 0x0
2019-04-23 18:50:20.359 T:1286595296   DEBUG: Thread Timer 1286595296 terminating
2019-04-23 18:50:20.392 T:1916417584   DEBUG: Keyboard: scancode: 0x1c, sym: 0x000d, unicode: 0x000d, modifier: 0x0
2019-04-23 18:50:20.392 T:1916417584   DEBUG: HandleKey: return (0xf00d) pressed, action is Select

flirc press ‘enter’

2019-04-23 18:49:48.300 T:1895822048   DEBUG: CLibInputKeyboard::ProcessKey - using delay: 250ms repeat: 33ms
2019-04-23 18:49:48.301 T:1337975520   DEBUG: Thread Timer start, auto delete: false
2019-04-23 18:49:48.321 T:1916417584   DEBUG: Keyboard: scancode: 0x1c, sym: 0x000d, unicode: 0x000d, modifier: 0x0
2019-04-23 18:49:48.556 T:1337975520   DEBUG: Thread Timer 1337975520 terminating
2019-04-23 18:49:48.576 T:1916417584   DEBUG: Keyboard: scancode: 0x1c, sym: 0x000d, unicode: 0x000d, modifier: 0x0
2019-04-23 18:49:48.576 T:1916417584   DEBUG: HandleKey: long-return (0x100f00d) pressed, action is ContextMenu
2019-04-23 18:49:48.576 T:1916417584   DEBUG: Keyboard: scancode: 0x1c, sym: 0x000d, unicode: 0x000d, modifier: 0x0

again, we get 3 scan codes, and i’m assuming that ‘long-return’ means it’s getting interpreted as a long-press instead?

again, let me know if there’s anything i can add

sam_nazarko · 24 April 2019 00:51

I don’t have a FLIRC so can’t advise much.
Has anyone tried their FLIRC on another Linux Kodi system to rule out an OSMC problem?

Sam

sam_nazarko · 24 April 2019 00:56

Looking at this further, FLIRC seems to repeat key presses that would’ve been filtered out by CLinuxInputDevices. This won’t be the case with the libinput implementation.

I’m not sure why it’s doing this – but ideally this needs to be fixed with FLIRC as it will affect more platforms than OSMC

epicwomble · 24 April 2019 01:07

yep, used to run Librelec on Raspberry pi, and then on intel NUC. using the same FLIRC dongle without any issue.

fzinken · 24 April 2019 01:12

With Kodi v18/Leia?

sam_nazarko · 24 April 2019 01:12

Indeed – that is the question.

epicwomble · 24 April 2019 01:34

yes with 18.1. I only recently swapped to the Vero4k as my DB was already on v18 schema since I upgraded to 18 before my vero arrived, hence running NUC on libre, with the FLIRC dongle via harmony without any issue.

I have just tried bluetooth though, with the harmony and that exhibits the same double press issue.

if I set the harmony to 300ms delay between sending commands it does improve it significantly, but does still happen, just not as often.

epicwomble · 24 April 2019 02:28

Ok some good news. when using logitech with flicr profile, if you set Command Repeats to 0 for the device in harmony setup, the problem goes away, you can also then reduce down the input delay back to 0ms.

Phydeaux · 24 April 2019 02:40

Same issues with double presses from a single keypress as others report using FLIRC. Three Vero 4k systems now unusable without breaking out the Vero remotes (yuck). And, yes, Leia 8.1 (LibreELEC) working fine on two other systems with FLIRCs.

RLW

TheDarkKnight · 24 April 2019 12:36

I will test my FLIRC with Kodi 18.2 on Windows 10 tonight to see if I get the same multiple key press issue.

I have also noticed that sometimes when pressing the “Enter” key via my Philips Pronto, Kodi is mixing the IR code up with the “C” key and shows the context menu instead of selecting the highlighted item.

This wasn’t an issue in Kodi 17.6 on OSMC; it all worked perfectly before.

@sam_nazarko what exactly has changes within OSMC and / or Kodi regarding IR handling for 2019-04 update / Kodi 18.2?

damianh · 24 April 2019 12:40

@TheDarkKnight i think that’s what i flagged in the second block, it’s interpreting it as [edit: a long press] “HandleKey: long-return (0x100f00d) pressed, action is ContextMenu” rather than “HandleKey: return (0xf00d) pressed, action is Select”