Posts by HiassofT

    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

    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