IR woes with vero 4K+

Help and Support Vero 4K / Vero 4K +
1

Hi, ever since I got my vero4K+ I’ve been happy with everything, except for IR remote performance. To be clear I do not use the Vero remote, rather as I have a Samsung TV I use my Samsung remote. Before I bought the 4K+ I used a rPi 3B with OSMC. Switching the IR profile to the Samsung, and buying an GPIO based IR receiver worked great on the rPi.

Fast forward to the 4K+ and as soon as I changed the IR profile to my Samsung all the buttons work like they did on the rPi, however the 4K+ registers button presses at a different rate or some kind of duplication is going on, as if I use the direction buttons for example with 2-3 close succession presses, the ‘cursor’ would move about 10 spots - with the accompanying audio clicks.

I have uploaded a debug log here:
https://paste.osmc.tv/xigaqecoci

Your assistance would be greatly appreciated.

PS: This phenomenon does not happen when I use network based remote (eg: iPhone with Kodi Official Remote)

2

The Samsung profile may need re-recording on the Vero 4K +
Have you used the IR extender to improve the signal?

3

Yes Sam I have used the extender since day 1, as I discovered that the reception is pretty poor with out it.

How does one go about re-recording a profile?

4

Have you tried without the receiver? If both receivers are within range then they will cancel each other out. This is intentional.

Sam

5

I have unplugged the receiver. I have the same experience.

6

In which case I would suggest recording a new profile with irrecord

Sam

7

Is there a guide on how that can be accomplished?

8

See Vero 4k and xbox one remote - #40 by Michael_Gombkoto

9

Thanks Sam, will do.

10

I might have a similar problem with my Vero 4K+.
I’m also using an IR remote (Philips Pronto) and the osmc-remote-lircd.conf with some additional buttons defined.
A few weeks back I noticed that buttons sometimes register multiple times, e.g. when watching a video and pushing the “right” button to seek forward 10s each time, sometimes it seeks all through to the end of the video.

I’ve captured a debug log and did a grep 'KEY_RIGHT\|SeekTime\|HandleKey' kodi.logto filter out the relevant lines:

2020-02-08 19:22:56.464 T:4049597152   DEBUG: LIRC: - NEW 6a 0 KEY_RIGHT linux-input-layer (KEY_RIGHT)
2020-02-08 19:22:56.480 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:22:57.275 T:3355902688   DEBUG: SeekTime - seek ended up on time 222.055
2020-02-08 19:22:58.523 T:4049597152   DEBUG: LIRC: - NEW 6a 0 KEY_RIGHT linux-input-layer (KEY_RIGHT)
2020-02-08 19:22:58.561 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:22:59.322 T:3355902688   DEBUG: SeekTime - seek ended up on time 234.651
2020-02-08 19:22:59.397 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:22:59.441 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:22:59.481 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:22:59.520 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:22:59.603 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:22:59.686 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:22:59.898 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:23:00.188 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:23:00.356 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:23:00.437 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:23:00.646 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:23:00.688 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:23:00.939 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:23:01.189 T:4069871616   DEBUG: HandleKey: 168 (0xa8, obc87) pressed, action is StepForward
2020-02-08 19:23:02.193 T:3355902688   DEBUG: SeekTime - seek ended up on time 245.504

As you can see, there are two KEY_RIGHT button presses.
The first one triggers a +10s seek as expected. The second one seems to trigger multiple “HandleKey” events altough only a single button press was registered by LIRC.

Any idea what could be causing this?
I’m on the current version, i.e. all regular updates are applied.

Sebastian

11

I was having similar problems originally (while working with a JP1 programmable remote). Initially, I was working with the Samsung conf, but switched to the hauppage (and custom programmed my own version with all the codes to make my remote and lirc.conf match up, I added a bunch of codes because my programmable remote has lots of buttons to work with).

The repeating buttons is not a new problem with kodi, LIRC + XBMC = Repeating Remote Buttons

there is a advancedsettings.xml property that can set a time before repeats registered, for example to not repeat unless the button is held for 2 seconds

<remoterepeat>2000</remoterepeat>

I seem to recall that there was some update to lirc that solved it for me…

12

Thanks, I’ll try that, but I’m not too optimistic here.
For one, it used to work with the exact same config until a while ago.
I’m aware of the “bouncy buttons” issue that can usually be fixed by setting the repeat delay, but this one feels different.
I’m also not sure if we would not see two (or more) consecutive keys logged by lirc in that case.

In my case, I can e.g. scroll down a list one item at a time 90% of the time, and suddenly it moves through the next 10 items without me having to hold the button.

Sebastian

13

I just tested with the remoterepeat-option in advancedsettings.xml.
As expected, it didn’t make any difference regarding the issue.

Sebastian

14

Did you record your profile on the Vero 4K +?

Sam

15

No, I didn’t record any of the IR codes - they’re all “synthetic”, i.e. I entered them as RC5 codes into my remote’s configuration (not sure if you’re familiar with the Philips Pronto remotes or the code format it uses).

This is the lircd.conf I’m using:

# Please make this file available to others
# by sending it to <lirc@bartelmus.de>
#
# this config file was automatically generated
# using lirc-0.9.0-pre1(default) on Thu Jan  8 11:26:07 2015
#
# contributed by  Dilligaf
#
# brand:                     OSMC
# model no. of remote control:
# devices being controlled by this remote:
#

begin remote

  name  OSMC
  bits            5
  flags RC5|CONST_LENGTH
  eps            30
  aeps          100

  one           872   807
  zero          872   807
  plead         886
  pre_data_bits   8
  pre_data       0x84
  gap          107676
  toggle_bit_mask 0x800

      begin codes
          KEY_HOME                 0x0F
          KEY_INFO                 0x10
          KEY_UP                   0x11
          KEY_DOWN                 0x13
          KEY_LEFT                 0x15
          KEY_RIGHT                0x12
          KEY_OK                   0x14
          KEY_BACK                 0x16
          KEY_TITLE                0x17
          KEY_PLAYPAUSE            0x18
          KEY_STOP                 0x19
          KEY_REWIND               0x1A
          KEY_FASTFORWARD          0x1B

# see /usr/share/kodi/system/Lircmap.xml, device="linux-input-layer" for key names
          KEY_RED                  0x0A
          KEY_SUBTITLE             0x0B
          KEY_SUBTITLE             0x0C
          KEY_TITLE                0x0D
          KEY_LANGUAGE             0x0E
          KEY_POWER                0x1C
      end codes

end remote

Here’s a screenshot of the remote configuration:

34
34624×706 138 KB

So the codes the remote sends are “clean” by definition.

Sebastian

16

I would still try irrecord, and see if the codes are being received as expected.

17

I’ll do that (it’ll be later today, though), but I don’t think that there’s anything wrong on that end.

Sebastian

18

I quickly tried with two buttons - not sure if I did it right.
I ran irrecord /tmp/lircd.conf -d /dev/lirc0 (after copying my lircd.conf to /tmp).
It asked me to enter the button names and then to press the corresponding button.
I tried with the KEY_UP and KEY_RIGHT buttons and this is what I got in “/tmp/lircd.conf.conf”:

      begin codes
          KEY_UP                   0x11
          KEY_RIGHT                0x12
      end codes

Looks about right to me.
I ran a diff over my “production” config and the newly generated one - they only differ in the amount of buttons and the name/comments, i.e. the signal timing definitions are identical.

In my original log output, don’t you find it strange that a single event received by lirc triggers this flood of “HandleKey” calls almost a second later?

Sebastian

19

I do – my guess is Kodi is interpreting it as a held button. If you hold the buttons for a second or so instead of pressing them, does it behave better?

20

Nope, doesn’t make a difference.
As said before, it works as expected 90% of the time, but occasionally it’s like the key press event is “stuck in the pipe”.
This happens with all buttons, I guess. It’s mostly noticeable with the cursor keys (due to the nature of their use) and the play/pause key.

Sebastian