Posts by HiassofT

  • MCE missing IR Protocols

    Can you try a clean install of 7.95.3 on a separate SD card and see if this works?

    Do you have any local config/settings installed in /storage/.config/udev.rules.d, /storage/.config/rc_keymaps or autostart.sh? If yes, remove them, they could be interfering.

    Also please post the output of these 2 commands on your non-working setup (without your ir-keytable in autostart):

    Code
    dmesg | paste
ir-keytable -v -a /etc/rc_maps.cfg -s rc0 2>&1 | paste

    so long,

    Hias

  • LibreELEC 7.0.3 build with new, reworked Wolfson/Cirrus driver

    Could you try setting the audio configuration to Fixed, for example 96kHz and see if you still get clicks?

    The driver for the WM5102 soundchip (which comes from the upstream linux kernel) is designed to be run at a fixed internal clock rate which is a multiple of the samplerate. This means it can support 32kHz, 48kHz, 96kHz, 192kHz (or 44.1, 88.2, 176.4kHz) without needing to change the internal clock. But switching between these 2 families, eg from 44.1kHz to 48kHz is tricky: the internal clock needs to be reconfigured which can cause glitches.

    Muting the outputs is also a little bit tricky and the S/PDIF output doesn't have a mute setting at all - so it's not really easy to mute all outputs.

    So, I'm aware of possible problems but currently don't have a solution for that that'd work for all configurations.

    I have to add that I've been using the card with S/PDIF-out and Line-out and so far didn't experience any loud clicks yet.

    so long,

    Hias

  • JustBoom DAC Zero

    Something really odd is going on with the RPi0. I haven't soldered on the GPIO connector so I did a quick test with dtoverlay=rpi-dac (this will work even without a soundcard installed) and could reproduce the issue with the 7.95.2 build:

    When selecting the ALSA soundcard in settings my monitor went blank for a very short time, then came back immediately. GUI and ssh were still working.

    Then (maybe when the sounddevice was closed after the 1min idle time, didn't time it) the screen went completely black.

    Still, ssh working fine and nothing in dmesg or kodi log (didn't have kodi debug logging active though).

    At this point I tried running "tvservice -s" and it just locked up. Same with "vcdbg log msg". Seems like the GPU has crashed.

    I thought maybe it had something to do with GPU resampling so rebooted and disabled it in audio settings. Then, when changing audio device from ALSA to HDMI the screen went black and the RPi crashed (ssh down).

    Pulled the plug, kodi came up with ALSA audio and software resampling. Changing audio to HDMI crashed the RPi0 again.

    so long,

    Hias

  • LibreELEC 7.0.3 build with new, reworked Wolfson/Cirrus driver

    Quote from tomasz1500


    One more problem - I get loud clicks between tracks when playing some albums on Tidal, or changing youtube videos..
    My speakers are pretty loud, but I think there should beno clicks at all.
    Is there a fix for this?
    I tried to set the option 'keep audio device alive' to 'always' , but no difference


    Do you also get these clicks when playing local music files?

    So far I haven't noticed these. There'll be a quite faint click when the audio card is turned off after the default 1min idle time, but that was it.

    You could try changing the resampling quality in system settings->audio (make sure you are in "Advanced" or "Expert" mode) an see if that makes a difference. And/or try changing the output configuration to fixed.

    Last but not least it could also be a problem with the audio/video tracks you are playing.

    so long,

    Hias

  • Problem with vdr.backend and IR GPIO

    This sounds a lot like this well known issue: lirc_rpi is sensitive to interrupt latency · Issue #906 · raspberrypi/linux · GitHub Unfortunately there's not much we can do about it.

    Since you seem to have an IR receiver integrated on your DVB receiver I'd recommend using that, ideally with the remote that came with it.

    You can use other remotes as well if they use the rc-5 protocol - for example a hauppauge remote should work. In this case you'll have to load the ir-keytable manually, eg with a "ir-keytable -w /usr/lib/udev/rc_keymaps/hauppauge" in autostart.sh

    so long,

    Hias

  • IR-KEYTABLE without LIRC / LIRCD

    Using ir-keytable on LE is rather simple: just drop your keymap in .config/rc_keymaps and it'll be automatically picked up by ir-keytable -a (run from standard udev rule).

    I'm doing this for about half a year now on RPi, have this line in config.txt

    Code
    dtoverlay=gpio-ir,gpio_pin=5,gpio_pull=1,rc-map-name=rc-hauppauge


    and placed a slightly modified hauppauge keymap in rc_keymap.

    If you've done this before it's a piece of cake on LE as well :)

    so long,

    Hias

  • IR remotes: eventlircd interfering with longpress support?

    Unfortunately not yet. Kodi still can't cope with a several linux input keycodes, eg KEY_OK, KEY_CHANNELUP etc, they all result in XBMCK_UNKNOWN.

    But there's a workaround: you can use a custom lircd.conf file (if you are using userspace lirc) or a custom rc-keymap (if you are using in-kernel decoding) and substitute the problematic keycodes with working ones (eg KEY_ENTER instead of KEY_OK). Then you can disable eventlircd, kodi will see the linux input events and long-press works.

    You'll also have to make sure the kodi http://remote.xml/keyboard.xml match the codes you are using, so that's mainly a solution for more experienced users.

    so long,

    Hias

  • 7.95.1 - lirc not working correct on rpi

    Just verified: the tools/lirc-make-devinput from the lirc source is picking up headers from the build host and due to cross-compiling the generated input_map.inc won't overwrite the shipped input_map.inc files (as a normal build would do) - so there's another risk of differing files during compilation.

    I'm already working on a patch, will drop you a line tomorrow after I ran some tests.

    so long,

    Hias

  • 7.95.1 - lirc not working correct on rpi

    Quote from inusasha


    Hmm, I had now tested the 7.95.2 image from website and this image is working...
    A clean build of the tag 7.95.2 does not work...

    Which OS are you running on your build system?

    Could you check the build files - here with Debian Jessie (and ancient kernel headers) it looks like this:

    Code
    hias@tv:~/rpi/libreelec-8.0$ grep -r -l KEY_RIGHT_UP build.LibreELEC-RPi2.arm-7.95.2/lirc-0.9.4c/.armv7ve-libreelec-linux-gnueabi/
hias@tv:~/rpi/libreelec-8.0$ grep -r -l KEY_RIGHT build.LibreELEC-RPi2.arm-7.95.2/lirc-0.9.4c/.armv7ve-libreelec-linux-gnueabi/
build.LibreELEC-RPi2.arm-7.95.2/lirc-0.9.4c/.armv7ve-libreelec-linux-gnueabi/lib/input_map.inc
build.LibreELEC-RPi2.arm-7.95.2/lirc-0.9.4c/.armv7ve-libreelec-linux-gnueabi/lib/.libs/input_map.o
build.LibreELEC-RPi2.arm-7.95.2/lirc-0.9.4c/.armv7ve-libreelec-linux-gnueabi/lib/.libs/liblirc.so.0.0.0

    The lirc build might be picking up headers from the build host, that could explain the differences.

    so long,

    Hias

  • 7.95.1 - lirc not working correct on rpi

    Thanks for the feedback, I was just able to reproduce this too (by doing a hard reset from the libreelec setttings addon).

    But this is another, one-off thing that most certainly doesn't have anything to do with the KEY_RIGHT issue.

    It's not a race between lircd and lircd-uinput, the condition is not on the socket (IIRC it was some time before, but that's not the case here).

    Although annoying, just do another reboot and it should be fine. Let's ignore that for now and focus on the KEY_RIGHT issue. Anything odd at systemctl status or input grabbing would be interesting to look at.

    so long,

    Hias

  • 7.95.1 - lirc not working correct on rpi

    Quote from inusasha


    I found another problem, which breaks some tests. When start with a new image (over img.gz), the complete remote is not working in first boot. (lircd-uinput is not running, condition file does not exist). after the second boot, all services are up and remote is working.
    This is independent from the LEFT/RIGHT-key problem, but some test, i had to repeat.
    :sick:


    This is very interesting info - I've suspected before that the lircd systemd config is racy and could lead to such things.

    If lircd-uinput is scheduled to start before lircd has created the socket the ConditionPathExist (on the socket) will fail and lircd-uinput won't start. The upstream systemd config does this differently, the socket is create via an independent systemd config (lircd.socket): LIRC / Git / [0d26f0] /systemd

    Could you please try to reproduce this and when it happens grab the systemctl status of the services? the boot log would also be interesting:

    Code
    systemctl status lircd@lirc0
systemctl status lircd-uinput@lirc0
systemctl status eventlircd
journalctl -a | paste

    It could be that we have another race between eventlircd and kodi grabbing the event input device. If kodi grabs it before eventlircd the button presses should show up as keyboard input instead of LIRC input in kodi.log and systemctl status eventlircd will contain an error message that the input device has already been grabbed by another process. So far I haven't seen this in the wild but could provoke it manually by stopping and then starting eventlircd while kodi is running.

    so long,

    Hias
    [hr]
    Please check another thing in addition to the stuff I just posted:

    With lsof and grep we can quickly verify who grabbed which input device. So if there's a race between kodi and eventlircd we should be able to verify it:

    First find out which event device is which physical/virtual device:

    Code
    LibreELEC:~ # grep . /sys/class/input/event?/device/name
/sys/class/input/event0/device/name:Logitech K400
/sys/class/input/event1/device/name:lircd-uinput
/sys/class/input/event2/device/name:eventlircd

    Now run lsof to see which process is using which input device:

    Code
    LibreELEC:~ # lsof | grep /dev/input/event
268     /usr/sbin/eventlircd    /dev/input/event1
436     /usr/lib/kodi/kodi.bin  /dev/input/event0
436     /usr/lib/kodi/kodi.bin  /dev/input/event2


    Here we see that kodi is using event0 (my logitech keyboard) and event2 (eventlircd, for receiving BTN_events) while eventlircd is reading from lircd-uinput. That's fine so far.

    But if I restart eventlircd while kodi is running kodi will grab the lircd-uinput device, and eventlircd can't grab it and errors out. So eventlircd is bypassed.

    Code
    LibreELEC:~ # systemctl stop eventlircd
LibreELEC:~ # systemctl start eventlircd
LibreELEC:~ # lsof | grep /dev/input/event
436     /usr/lib/kodi/kodi.bin  /dev/input/event1
436     /usr/lib/kodi/kodi.bin  /dev/input/event0


    And we can see eventlircd status is failed:

    Of course we shouldn't manually restart eventlircd while kodi is running as this will provoke issues - this was just to illustrate the error scenario that could happen when there's a race between eventlircd and kodi grabbing the lircd-uinput device.

    so long,

    Hias

  • 7.95.1 - lirc not working correct on rpi

    I ran some tests with 7.95.2 but unfortunatley couldn't reproduce the issue locally. But I have a few more things for you to try to narrow down the issue.

    First of all, the --release=XXX settings of lircd and lircd-uinput have to match, otherwise we get repeating keys. lircd defaults to no release lirc event, lircd-uinput defaults to _UP.

    The --release option of eventlircd can be dropped though, kodi doesn't seem to know what to do with that.

    For testing, install the system tools addon (in the LibreELEC programs addon catetory), that'll give you evtest (you can also use ir-keytable to monitor input events but you need to know which input event device to monitor - evtest will display a nice list on startup you can select from).

    Then, stop kodi, eventlircd, lircd and lircd-uinput: and verify they are really gone (stopping lircd via systemctl doesn't seem to work, therefore killall was needed):

    Code
    LibreELEC:~ # systemctl stop kodi
LibreELEC:~ # systemctl stop eventlircd
LibreELEC:~ # systemctl stop lircd-uinput@lirc0
LibreELEC:~ # systemctl stop lircd@lirc0
LibreELEC:~ # killall lircd
LibreELEC:~ # ps | grep lirc
  590 root       0:00 grep lirc

    Now start lircd manually. I did this via the following command line (you need to use /etc/lirc/lircd.conf.rpi as a configuration file):

    Code
    LibreELEC:~ # /usr/sbin/lircd --loglevel=debug --release=_UP --nodaemon --driver=default --device=/dev/lirc0 --output=/run/lirc/lircd-lirc0 --pidfile=/run/lirc/lircd-lirc0.pid /storage/.config/lircd.conf
Warning: cannot open /etc/lirc/lirc_options.conf
lircd-0.9.4c[592]: Debug: lircd:  Opening log, level: Debug
lircd-0.9.4c[592]: Warning: Running as root
lircd-0.9.4c[592]: Info: Using remote: hauppaugeHias.
lircd-0.9.4c[592]: Notice: lircd(default) ready, using /run/lirc/lircd-lirc0


    In another terminal verify that lircd is running correctly. Start irw, press a few keys and then stop irw with ctrl-c


    The count (second value) should go up if you hold down the key and it's repeating. When releasing the key you should see a "virtual" release key with the KEYNAME_UP event (_UP as configured with --release=_UP)

    If that's working fine, stop irw and run lircd-uinput. Again press some keys:


    Here note that event code at the end: 106:1 means keycode 106, pressed, 106:0 means released.

    If the --release setting doesn't match the one from lircd lircd-uinput won't generate a input release event, resulting in endlessly repeating keys.

    You can verify that using evtest. With lircd and lircd-uinput both set to _UP you should get this:


    value 1 (at the very end) means initial keypress, 2 is repeating keypress, 0 is release.

    In the snipped part evtest reports all the key/eventcodes it'll handle, but doesn't show a symbolic name for keycode 614 decimal / 0x266 hex etc - evtest seems to be too old to know about these.

    Doing the same test with ir-keytable instead of evtest results in this output:

    Code
    LibreELEC:~ # ir-keytable -d /dev/input/event1 -t
Testing events. Please, press CTRL-C to abort.
1486155236.010594: event type EV_KEY(0x01) key_down: KEY_RIGHT(0x0001)
1486155236.010594: event type EV_SYN(0x00).
1486155237.015482: event type EV_KEY(0x01) key_down: KEY_RIGHT(0x0001)
1486155237.015482: event type EV_SYN(0x00).
1486155237.052144: event type EV_KEY(0x01) key_down: KEY_RIGHT(0x0001)
1486155237.052144: event type EV_SYN(0x00).
1486155237.074032: event type EV_KEY(0x01) key_up: KEY_RIGHT(0x0001)
1486155237.074032: event type EV_SYN(0x00).


    It's basically the same output like with evtest, but the press/hold/release value isn't reported.

    Once we've verified that lircd-uinput is working correctly we can bring eventlircd into play. Let's do that without the --release option first:

    Code
    LibreELEC:~ # /usr/sbin/eventlircd -f -vvv --evmap=/etc/eventlircd.d --socket=/run/lirc/lircd
eventlircd[648]: input device /dev/input/event1: events of unsupported event type EV_REP will be discarded
eventlircd[648]: input device /dev/input/event1: grabbed
eventlircd[648]: input device /dev/input/event1: created output event device

    Now let's verify with irw that eventlircd correctly translates the input events into lirc events:


    Here I pressed right two times for a longer period. During repeats the second value counts up, after release the next keypress with start with count 0 (here it counted from 0-8 two times).

    If you start eventlircd with the --release option you should also get the "virtual" lirc up events (here I used _UP_FROM_EVENTLIRCD just to make it clear where they are coming from):

    Code
    LibreELEC:~ # /usr/sbin/eventlircd -f -vvv --evmap=/etc/eventlircd.d --socket=/run/lirc/lircd --release=_UP_FROM_EVENTLIRCD
eventlircd[657]: input device /dev/input/event1: events of unsupported event type EV_REP will be discarded
eventlircd[657]: input device /dev/input/event1: grabbed
eventlircd[657]: input device /dev/input/event1: created output event device
    Code
    LibreELEC:~ # irw /run/lirc/lircd
6a 0 KEY_RIGHT devinput
6a 1 KEY_RIGHT devinput
6a 2 KEY_RIGHT devinput
6a 0 KEY_RIGHT_UP_FROM_EVENTLIRCD devinput

    Please repeat these steps and compare the output with mine. Then repeat the test with lircd and lircd-uinput both started with --release=_FAKEUP (or something like that that's not _UP). Please post all the outputs so I can also have a closer look at them.

    so long,

    Hias

  • 7.95.1 - lirc not working correct on rpi

    Quote from inusasha


    EDIT: in /usr/include/linux/input-event-codes.h is KEY_RIGHT_UP and KEY_LEFT_UP defined... may we need an other SUFFIX, then _UP?
    (edit1.b: was introduced with v4.7-rc6)


    Cool, this looks like a very possible explanation for your issues!

    I'll run some tests myself and see if I can reproduce - not sure why I haven't seen any issues yet (if KEY_RIGHT_UP is now a valid event I should be able to see some odd behaviour).

    I'll report back after I finished my tests (could maybe take until tomorrow or so).

    so long & thanks a lot for digging into this,

    Hias

  • JustBoom DAC Zero

    Quote from JustBoom


    @ Hias - will test that sure!

    Only thing is though - why would that I2S thing effect the Pi Zero but not the Pi B+ or any of the others?

    Phil added that I2S thingy (actually changing the DMA priorities) because under some conditions the I2S stream would get out of sync and result in garbage output (mostly noise or so). That only happened on the RPi3 and only with the downstream DMA code but not the upstream one - so that was very mysterious as well (at least to me).

    I might be barking up the wrong tree, but the mysteriousness of the RPi0 issue remembered me of the other mysterious one :)

    BTW: Another interesting test would be to check if you get the same issues on Raspbian if you use kernel 4.9 (sudo BRANCH=next rpi-update).

    so long,

    Hias

  • 7.95.1 - lirc not working correct on rpi

    Thanks again for testing!

    I'm not quite sure if the lirc socket check is actually the culprit, so could you please also test the milhouse builds in between? Do a simple bisect until you found the first build that introduces the issue (for example #0101 OK, #0102 not OK) - that should help us narrow down the exact cause.

    Full list of builds with easy access is here: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)

    so long,

    Hias