Posts by HiassofT

    Hi, I recently switched from Openelec to LibreELEC. I added the files lircd.conf, Lircmap.xml and remote.xml on LibreELEC 8.1. It didn't work until I turned on "Enable Lirc". After this it worked perfectly fine, but after some time it stopped working completely. I don't understand what's wrong. Under Openelec 5.95.3 everything was fine. Turning "Enable Lirc" on and off allows me to use my remote once, but afterwards it stops working. The remote I'm using is the Xbox one remote. I also added dtoverlay=lirc-rpi to the config.

    Please post the output of these commands when the remote stopped working:

    Code
    journalctl -a | paste
    dmesg | paste
    systemctl status lircd | paste
    systemctl status lircd-uinput | paste
    systemctl status eventlircd | paste

    so long,

    Hias


    Nothing special, I just update LE v8.0.2MR through the le-addon. After reboot the entry 'lirc' was present and active.


    My device: Zotac Zbox ci321nano with LE x86_64_generic

    I could now (partly) reproduce the issue on RPi and understand what's going on:

    In LE 8.0.x lirc is automatically enabled if an IR receiver supporting the /dev/lirc interface is detected. If you go to LE Settings->Services "Enable Lirc" will be set to on.

    But although lirc was enabled it wouldn't be started unless you had a .config/lircd.conf file or were using the lirc_rpi driver on RPi or had an old xbox dvd remote dongle connected. As the remote buttons were still decoded by the kernel everything worked as before and we all seem to have missed the fact that Lirc was actually enabled when it shouldn't have been...

    In 8.1.0 Lirc handling changed: on a fresh install it won't be enabled by default, and if you enable it it will actually be started - using a default lircd.conf file if you didn't provide your own.

    So, on a 8.0.x->8.1.0 upgrade you are now presented with an enabled and actually running lircd.

    The one thing I don't quite understand, and also couldn't reproduce so far, is why you get the "double buttonpresses" on Generic.

    When lircd starts it will automatically disable in-kernel decoding. OTOH there's also the ir-keytable auto-configuration running which enables in-kernel decoding for MCE and a bunch of other remotes. Although that leads to 2 configuration services fighting against each other I had expected lircd to be run last, and thus win, and lead to remote buttons only be decoded by lircd, not the kernel - this is also what I got in my tests on RPi.

    It would be great if someone plagued by double-presses could do a few tests on 8.1.0, maybe that'll give some clues about why that happens:

    Enable lirc in LE settings, reboot, then run the following commands:

    Code
    ir-keytable -r | paste
    journalctl -a | paste

    so long,

    Hias

    Make sure lirc is disabled in LE settings.

    In 8.0.2 enabling lirc didn't have any effect unless you also created a .config/lircd.conf file (or were using lirc_rpi on a RPi). In 8.2 this is changed and now lirc will use a default config if you enable it in LE settings.

    so long,

    Hias

    Then it will be better to disable [lirc] in the setting by default ... less confusion

    Lirc shouldn't be enabled by default, you have to manually turn that on.

    If it behaved differently on your setup it would be great if you could post steps how to reproduce this.

    IIRC the only cases where lirc was automatically enabled in the past were if you used lirc_rpi on the RPi or if you had an old xbox dvd remote receiver plugged in.

    so long,

    Hias

    LibreELEC supports MCE remotes out-of-the box without having to run lircd - they are handled by the Linux kernel.

    In general, keep lirc disabled and if you need to configure your remote use ir-keytable. Lirc is meant to be used only in very special cases, with odd remotes that aren't supported by the linux kernel / ir-keytable.

    If you enable lirc eg with an MCE remote it can happen that the button presses are decoded both by the kernel and by lirc, and you get double actions.

    so long,

    Hias

    Hmmm, never seen such a thing before. Which LE version / system / kernel was used, and which USB DVB stick?

    "cat /sys/class/rc/rc0/protocols" could give some clues if that's maybe an ir-keytable or kernel issue. Also test if changing protocols directly via sysfs "echo nec > /sys/class/rc/rc0/protocols", then cat again to check, works.

    so long,

    Hias

    No problem, feel free to ask! Remote handling in Kodi is somewhat confusing, took me a while to understand it as well :)

    The LIRC events from eventlircd will show up with "devinput" as remote name (with lirc they'd show up as the remote name defined in lircd.conf).

    Hint: enable debug logging in kodi and then check .kodi/temp/kodi.log. A lirc event from eventlircd will look like this:

    Code
    12:40:51.762 T:1943990288   DEBUG: LIRC: Update - NEW at 10148446:6c 0 KEY_DOWN devinput (KEY_DOWN)
    12:40:51.763 T:1943990288   DEBUG: OnKey: 167 (0xa7, obc88) pressed, action is Down

    "devinput" is the "remote name".

    Keyboard input OTOH looks like this:

    Code
    12:47:40.167 T:1943990288   DEBUG: Keyboard: scancode: 0x6c, sym: 0x0112, unicode: 0x0000, modifier: 0x0
    12:47:40.167 T:1943990288   DEBUG: OnKey: down (0xf081) pressed, action is Down

    so long,

    Hias

    It's a bit tricky, but for self-contained binary addons like tvheadend without dependencies it's doable. Main problem is getting the latest ZIP . You can do this with that shell script:

    name it eg "get-addon.sh" and then run "sh get-addon.sh service.tvheadend42"

    Then stop your current tvheadend (via systemctl stop service.tvheadend42), unzip the file in /storage/.kodi/addons, make sure all files in the bin subdir have executable permissions (otherwise to a chmod +x /storage/.kodi/addons/service.tvheadend42/bin/*), then start it via "systemctl start service.tvheadend42".

    That's basically what kodi is doing as well.

    so long,

    Hias

    RobertPaulsen also please upload full kodi debug logs from the failing 8.0.2 build and the 8.2 preview-build above and verify that the system date/time is set correctly.

    HOW TO:Provide Logfile - LibreELEC

    Especially on systems without an RTC, like the RPi, failing to get the current date/time from NTP can have funny effects with certs (system will then fall back to image build time which may or may not be in the certificate valid-from/valid-to period).

    so long,

    Hias

    Thanks again for testing, your feedback was really helpful!

    The Milhouse build you tested is the current development state of the next major LibreELEC release (9.0) with Kodi 18 Leia. It's still a long way there, about half a year or so.

    But we are planning on releasing a 8.2 version soon (within the next weeks), with Kodi 17 .4 Krypton and several updates/fixes.

    Could you test if this build works, that's our current 8.2 development state:

    LibreELEC-RPi2.arm-8.2-devel-20170808010044-r25961-g2568ed687.tar

    If my suspicion (libudev/systemd bug) is correct that build should have the same issue as 8.0.2 as systemd is the same version as in 8.0 builds (Milhouse builds have a newer version). But maybe my guess was wrong and the issue is caused by something else that's already fixed in 8.2 :)

    As for the KEY_OK/EXIT: I called that a workaround because you should not need to change that - LE should be able to cope with unmodified keymaps and there's a real bug present (eventlircd not working as expected).

    so long,

    Hias

    Thanks a lot, again, for testing!

    From the system/udev side everything looks fine, these were the 2 lines I was looking for:

    Code
    eventlircd_enable=true
    eventlircd_evmap=default.evmap

    So the problem most certainly resides in libudev or eventlircd. Unfortunatley eventlircd is very quiet and nothing was logged to the journal that could provide additional hints.

    Before I go down the rabbit hole of digging into eventlircd/libudev - which could take me a while - there's one last thing I'd like you to do: Could you do a quick test with the latest milhouse build, using your existing rc_maps.cfg config, and see if eventlircd picks up the input device there (post the output of "lsof | grep /dev/input")? That build contains a newer systemd version, so if it's really a libudev/systemd issue there's a slight chance that could already be fixed.

    Builds are available from here: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) (just pick the latest, currently #0802). But better use a separate SD card for testing - going back to 8.0.2 will result in a mess because several databases, addons etc will have been updated to newer versions.

    As for KEY_ENTER/BACK being slower: that's normal and caused by the long-press support in Kodi, configured via the default keyboard.xml file:

    Code
    <return>Select</return>
    <return mod="longpress">ContextMenu</return>
    <enter>Select</enter>
    <enter mod="longpress">ContextMenu</enter>
    ...


    That feature allows you to map different functions to a key/button, depending on if you press it shortly or longer. That feature is only available on keyboards, not on (remote-) events that come in via the lirc socket.

    For a full list of keycodes supported in Kodi best look into the source code (the keyMap definition at around line 120): xbmc/LinuxInputDevices.cpp at Krypton · xbmc/xbmc · GitHub

    so long,

    Hias

    Thanks a lot for testing and for the logs!

    The core issue is that eventlircd isn't picking up the input device at all and therefore the button presses end up as keyboard input in kodi (and kodi doesn't "understand" many of the keycodes, thus the "TranslateKey returned XBMCK_UNKNOWN" messages).

    I have no idea why kodi suddenly seems to recognize the input as obc events in the second log. At the beginning of the log we have the "Keyboard: ..." and "OnKey: ..." messages as expected. Then the screensaver kicked in, after that there are no longer any "Keyboard: ..." events, only "OnKey: " with obcXXX codes. Odd.

    Coming back to the eventlircd issue, could you post the output of the following command?

    Code
    udevadm test -a add /sys/class/rc/rc0/input0/event0

    Then power down the RPi, unplug the DVB stick and power up the RPi without it. Then, run the following command:

    Code
    udevadm control -l debug

    Now plug in the DVB stick and then, after some 5 or 10 seconds, grab dmesg and journal output

    Code
    dmesg | paste
    journalctl -a | paste

    With this info I should hopefully get some clues where to start looking further - if it's an udev issue or an eventlircd issue.

    BTW: as a temporary workaround you can change the keytable to use keycodes that kodi understands. eg use KEY_ENTER instead of KEY_OK, KEY_BACK instead of KEY_EXIT etc.

    so long,

    Hias