Posts by HiassofT

    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

    Damn, everything looks OK so far. But I'm not giving up yet :)

    Could you enabling debug logging in kodi, reboot, then press some buttons on the remote, and then get us the kodi log?

    Code
    paste .kodi/temp/kodi.log

    Then disable both kodi and eventlircd (via systemctl stop).

    Next start eventlircd and check via lsof (as above) if it had picked up the /dev/input/event0 device.

    If that worked, start kodi. Check again via lsof who is using the event0 device. Then press some buttons, tell us if that worked and grab another kodi log.

    so long,

    Hias

    Thanks for the info! Unfortunately I still could not reproduce the issue here (tried with gpio-ir and a hauppauge dvb-t stick).

    Could you post the contents of your xbox_one keymap and the output of this command:

    Code
    udevadm info -a -n /dev/input/event0

    Do you have an local udev rules in .config/udev.rules.d/?

    As a very wild guess, could you try to disable joystick support in Kodi (Add-ons->My Add-ons->Peripheral libraries->Joystick support, then disable that addon), and then reboot?

    so long,

    Hias

    The eventlircd process running is fine, it's needed to feed the remote button presses into kodi.

    The table you are seeing in ir-keytable output is also OK, that's the name of default table loaded by the kerrnel and won't change if you override the map via ir-keytable. You can view the currently active map and protocol with "ir-keytable -r" - that should produce about the output as the table you loaded.

    Here's a thread with more details about working with ir-keytable: WD TV Live remote

    Since you already have a somewhat working configuration start with that, run "ir-keytable -t" to see if the scancodes are mapped correctly to KEY_ codes, and change your keymap file accordingly (change the 0x... scancodes in that file).

    If, for some reason, the correct KEY_ codes show up but don't make it into kodi, please run the following command after a fresh reboot (with kodi and everything else running) and post the output. Also your keymap file and rc_maps.cfg would be helpful.

    Code
    cat /proc/bus/input/devices
    lsof | grep /dev/input

    I've seen some odd reports that seemed like kodi picked up the input device (instead of eventlircd) and thus several buttons (like OK) weren't working. But so far I couldn't reproduce that issue reliably enough to analyze it. Maybe I'm barking up the wrong tree, but anyways, if you run into that every info will help me.

    so long,

    Hias

    Ah, yes, you are right about KEY_HOME (<start> code in kodi). The global section maps that to PreviousMenu, but in FullscreenVideo it's changed to OSD.

    Not 100% sure about the window names, have a look here for the list of Window IDs: Window IDs - Official Kodi Wiki - the links to Keymaps and Action IDs at the bottom of the page might also be worth a read.

    so long,

    Hias

    I haven't used Pulseaudio or Bluetooth audio devices myself yet, so my knowledge in that area is zero.

    But lrusak, who wrote that wiki article, is quite experienced in that area, so that information should be accurate.

    In that aspect the Wolfson / Cirrus cards work identical to all other ALSA cards, so it's better to post in the General Forum if you have questions about that.

    so long,

    Hias

    That looks like you are running into RPi issue #906 Issues · raspberrypi/linux · GitHub (sorry, stupid forum software thinks I'm posting spam because the title of the bug report contains the censored word "sens*t*ve" - just add 906 at the end of the URL to get to the details). Heavy USB traffic, like it's generated by DVB sticks, can interfere with proper operation of GPIIO IR receivers. Unfortunately there's no solution to that.

    Since your DVB stick has an IR receiver built in the best solution would be to use that, and disable the GPIO IR receiver (either by uncommenting the dtoverlay line in config.txt or by disabling lirc in LibreELEC settings).

    LibreELEC already ships with a keytable for the xbox one remote (let's hope it's the correct one) and the IR receiver of your DVB stick seems to support the remote protocol (NEC) as well.

    To get that working just create a .config/rc_maps.cfg file with the following content:

    Code
    * * xbox_one

    so long,

    Hias

    For 1 and 2 I'm using this:

    buttons mapped to KEY_EPG and KEY_HOME in keytable.

    In oder to get the EPG working I use the following Lircmap.xml

    Code
    <lircmap>
        <remote device="devinput">
            <guide>KEY_EPG</guide>
        </remote>
    </lircmap>

    The linux input events translated by eventlircd will show up as "devinput" lirc events in kodi.

    As for 3: that should be doable with mapping a button to KEY_PVR - that should map to <recordedtv> in the default kodi keymap for devinput and will then bring up the window via this entry in the default kodi remote.xml

    Code
    <recordedtv>ActivateWindow(TVRecordings)</recordedtv>

    so long,

    Hias

    We are only removing the driver for the old xbox USB IR receiver. You'll still be able to use the remote with another IR receiver that's compatible with it - eg the universal GPIO receiver on RPi or most built-in IR receivers eg on Intel NUCs.

    lirc_xbox doesn't support configuration via ir-keytable as it is an old lirc-only device driver.

    so long,

    Hias

    That post you mentioned is the right start. Follow the steps outlined there, and if something's not quite clear just ask.

    I'm currently putting a guide together which will be posted on the wiki, every feedback from you users is helpful to me.

    For me as a dev who's into that stuff it's the other way round, too many things are obvious to me and I might forget mentioning them. Knowing about these things and what's not really obvious to you will help me creating the guide.

    so long,

    Hias

    BTW: It's better to build a simple GPIO IR receiver (eg using a TSOP34138) which you can then use with the "gpio-ir" overlay.

    LibreELEC 9.0 will ship without the lirc_xbox driver (it's already removed from current Milhouse builds).

    Kernel is moving away from the old lirc drivers to the newer rc-core drivers (with in-kernel decoding support, you don't need userspace lirc for remotes). The lirc_xbox never made it into the upstream kernel, it was only added to OpenELEC (and kept in LibreELEC), and due to the ongoing changes in the kernel we can no longer support it. OpenELEC already removed it, and now we have to do the same as well.

    so long,

    Hias