Could you test with 8.1.0 and Milhouse? They have newer kernel and ir-keytable versions.
so long,
Hias
Could you test with 8.1.0 and Milhouse? They have newer kernel and ir-keytable versions.
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
The official 8.2 beta (numbered 8.1.0) has just been released: LibreELEC (Krypton) v8.1.0 BETA – LibreELEC
Could you try with that?
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:
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:
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
Yes, that's exactly what's happening. Lirc events received by kodi are translated by Lircmap.xml.
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:
#!/bin/sh
if [ $# -ne 1 ] ; then
echo "usage: $0 addon-id"
exit 1
fi
set -e
ADDON_NAME="$1"
DATADIR=$(xmlstarlet sel -t -v \
"/addon/extension/datadir[@zip='true']" \
/usr/share/kodi/addons/repository.libreelec.tv/addon.xml)
ADDONS_XML_GZ=$(xmlstarlet sel -t -v \
"/addon/extension/info" \
/usr/share/kodi/addons/repository.libreelec.tv/addon.xml)
wget -O - "$ADDONS_XML_GZ" | zcat > /tmp/addons.xml
VERSION=$(xmlstarlet sel -t -v \
"/addons/addon[@id='${ADDON_NAME}']/@version" \
/tmp/addons.xml )
ADDON_FILENAME="${ADDON_NAME}-${VERSION}.zip"
wget "${DATADIR}/${ADDON_NAME}/${ADDON_FILENAME}"
echo "addon $ADDON_FILENAME downloaded"
Display More
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
Thanks again for testing! It's very good to know that the issue is fixed.
I compiled that build from current 8.2 head (rev 2568ed687) with no additional modifications. Public 8.2 beta builds should be out soon after kodi 17.4 is released.
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
Could you test with this build: LibreELEC-RPi2.arm-8.2-devel-20170808010044-r25961-g2568ed687.tar
That's a current 8.2 branch build and Sky Ticket seems to work fine (no ssl errors).
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:
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:
<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?
Then power down the RPi, unplug the DVB stick and power up the RPi without it. Then, run the following command:
Now plug in the DVB stick and then, after some 5 or 10 seconds, grab dmesg and journal output
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?
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:
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
Untested, as I don't have such a card, but try adding this line to config.txt
Instructions on how to change config.txt in LibreELEC are here: Config.txt - LibreELEC
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.
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