Posts by HiassofT


    Both configs tested with 7.95.2 Hiassofts is working, my not...
    Very confusing..


    Thanks a lot for testing, and it's good to know that gpio-ir-recv is working fine!

    Did you add some special customizations or config settings?

    Please run a test with a clean installation of 7.95.2 and only the following line added to config.txt (keep everything else stock):

    Code
    dtoverlay=lirc-rpi


    Then, run the following command and post the output (we should see that lircd is running and using /etc/lirc/lircd.conf.rpi):

    Code
    ps | grep lirc

    It could well be that something's not 100% working correctly with userspace lircd. As I've tested with a different remote I can't rule out that something's wrong with the MCE remotes or lircd.conf.rpi config file. But that's just a guess,it would be great if we could narrow it down. Unfortunately I don't have an MCE remote so we'll need your help.

    Or it could also be that you need to add some lirc-rpi parameters to config.txt like gpio_in_pull=up.

    so long,

    Hias

    Thanks a lot for the feedback!

    MagnaVis  JustBoom could you run a test with my 7.0.3 build with Cirrus Logic audio card drivers?
    LibreELEC-RPi.arm-7.0.3-HiassofT.tar

    This build is official 7.0.3 version plus kernel 4.9 (as opposed to 4.4 in official 7.0.3) plus drivers for the cirrus card (the latter shouldn't hurt you in testing).

    I'm suspecting it could be something in the kernel, quite a lot has changed between 4.4 and 4.9. For example 4.4 includes an additional patch to the I2S driver that's not in 4.9 - not sure if this could be the culprit
    bcm2835-i2s: Reduce the TX DREQ threshold · raspberrypi/linux@3de2328 · GitHub

    so long,

    Hias

    I just did a test with a clean install of the latest preview of the upcoming 7.95.2 version and my remote worked fine.

    I've been using an RPi2, a gpio IR receiver, lirc-rpi overlay in the kernel plus a custom lircd.conf for my hauppauge remote (the default lircd.conf.rpi doesn't support that).

    Please run a test when the new 7.95.2 version is out, it should be released very soon.

    BTW: instead of using the lircd-rpi overlay you could also try using the gpio-ir overlay (the latter doesn't need userspace lirc but uses in-kernel decoding like most of the USB IR receivers do). To use it add the following line to config.txt (and remove the lirc-rpi overlay):

    Code
    dtoverlay=gpio-ir,gpio_pin=18,gpio_pull=1,rc-map-name=rc-rc6-mce

    adjust the gpio_pin and gpio_pull parameters as needed (they have the same meaning as the corresponding lirc-rpi parameters), if you want to use something else than a RC6 MCE remote change the rc-map-name parameter as well (see the module files in /lib/modules/<kernelversion>/kernel/drivers/media/rc/keymaps).

    so long,

    Hias

    Thanks a lot for testing!

    I've been in contact with popcornmix, he could reproduce the issue and told me Phil Elwell will have a look at it. Something really strange seems to be going on with the RPi zero - it's almost identical to the RPi1 B+ so it's rather puzzling why the RPi1 works fine but not the RPi0.

    I'll keep you posted if I hear of any updates on that issue.

    so long,

    Hias

    There's currently no option to disable eventlircd, the service will be started unconditionally.

    But eventlircd is configurable via udev rules - it'll only grab the input devices matched by the udev rules and translate their input events into lirc events (the current udev rules basically matches all IR receivers, i.e. all remote commands are run through this translation service).

    So another possibility to (logically) disable eventlircd is to create an empty udev rule file - the button-presses should then show up as input/keyboard events in kodi instead of lirc events.

    Code
    : > /storage/.config/udev.rules.d/98-eventlircd.rules

    One benefit of not using eventlircd is that long-press button handling should work in kodi. I haven't checked for quite a while, but about half a year ago there was no longpress support for lirc remotes, but it did work well if eventlircd was bypassed.

    But there are also several drawbacks:

    Most importantly bypassing eventlircd isn't tested too well in LibreELEC so there could be bugs.

    One issue I ran into was that Kodi couldn't handle quite a lot of the default input events on the RPi - most prominently "KEY_OK" but also KEY_CHANNELUP/DOWN and several other ones don't work. I've posted some more info on this issue on the XBMC/Kodi bugtracker half a year ago: #15797 (XBMCK_UNKNOWN returned for some key codes, unable to map with key id=xxx) – Kodi - TRAC

    x86 and RPi are quite different though, on x86 you have X11 running and probably some additional input/event translation in between (not 100% sure, never tried running OpenELEC/LibreELEC on x86). On the RPi there's no X11 and Kodi will be directly talking to the Linux input/event interface.

    So: if you see some unsupported key messages in kodi.log you'll probably have to change the ir-keytable.

    It's still quite puzzling why you have a non-working remote after every other reboot.

    Could you enable debug logging in Kodi and then post the kodi.log after you got a non-working remote?

    Also, when the remote is not working, try stopping kodi and see if you can receive any events with ir-keytable -t.

    Maybe the culprit is also some X11 service or configuration - I won't rule out anything at this point:)

    so long,

    Hias

    According to the infos on the hifiberry site the DAC+ Light uses a different DAC chip (ESS sabre) than the standard DAC+ (pcm5122). This means the hifiberry-dacplus overlay most certainly won't work.

    Not sure what the correct dtoverlay would be, there doesn't seem to be any matching one in the official RPi 4.4 and 4.9 kernels. Better contact the hifiberry guys about that.

    so long,

    Hias


    Unfortunately I don't have a RPi Zero (they still seem to be impossible to get) so can't test myself.

    Could you run a test with the latest Milhouse build? LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)
    Testing with a kernel 4.10-rc Milhouse build would also be interesting LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)

    If they also fail please post the output of tvservice -s before and after the display blanks and please also post the dmesg log after display blank.

    so long,

    Hias


    Also one more question : did anybody notice that when we connect RPi2 and Wolfson, some of the 8 big pins from Wolfson make contact with elements on the Pi board ? Is it supposed to be like this? I put some tape there not to short anything.


    This sounds like you are trying to use the original Wolfson card for the RPi1 (with 26 pin GPIO connector plus 8 pogo-pins for the P5 connetor). If that's the case - sorry, that won't work, you need to use the Cirrus card (with 40 pin GPIO and no pogo pins) on RPi2 (and all other B+ models with 40-pin GPIO connector).

    so long,

    Hias

    JustBoom it's the same for Kodi running under Raspbian (and probably OSMC as well), passthrough is only available if the soundcard provides an iec958 pcm (check with aplay -L).

    Testing with Raspbian might be easiest for you (just adapt the conf file and store it in /usr/share/alsa/cards). If you have a working conf file drop us a line and we can include it in LibreELEC.

    BTW: for the Hifiberry Digi we had to add a .driver_name to the kernel driver, otherwise ALSA would not have been able to distinguish between Hifiberry DAC (analog card) and Digi (SPDIF card).
    linux/hifiberry_digi.c at rpi-4.9.y · raspberrypi/linux · GitHub

    If no .driver_name is present ALSA falls back to using .name with underscores removed and truncated to 15 characters - which is too short if .name is snd_rpi_hifiberry_digi. You probably need to do the same for your justboom Digi/Dac drivers.

    so long,

    Hias

    Hi Eric!

    I've run into a similar issue during testing, the problem most certainly comes from the Krypton Confluence skin not really working with Jarvis. You could try uninstalling the Confluence addon, then the built-in Confluence skin should be used.

    But there may have been other (newer, possibly incompatible) addons installed and you'll have newer database versions (which might cause troubles when you later update to Krypton) so it'd be better to do a soft or hard reset.

    BTW: If you used the integrated update feature you'll most certainly be using the official LibreELEC versions, not my builds - check in the system info, my build should show up as "LibreELEC (HiassofT)" instead of "LibreELEC (official)". In that case better post in the Bug Reports forum.

    so long,

    Hias

    I've been working on a major driver rework, removing the need to add a ton of patches to upstream Linux code, fixing several outstanding issues and adding some new features.

    Here are builds based on LibreELEC 7.0.3:
    RPi: LibreELEC-RPi.arm-7.0.3-HiassofT.tar
    RPi2/3: LibreELEC-RPi2.arm-7.0.3-HiassofT.tar
    Source code: GitHub - HiassofT/LibreELEC.tv at 7.0.3-cirrus-ng

    Note: the name of the soundcard has changed from "snd_rpi_wsp" to "RPi-Cirrus".

    One of the new features is proper AC3/DTS passthrough support via S/PDIF, including setting the S/PDIF channel status bits. Choose "RPi-Cirrus, S/PDIF" for that, this device will mute all other analog outputs.

    To use the analog outputs (plus S/PDIF) choose "RPi-Cirrus Analog" - this works as before in the previous versions and you can customize the mixer routing (mixing line-in into the signal etc).

    Customizing the mixer settings is now done via a shell script (instead of the udev rule):

    Code
    .config/rpi-cirrus-config.sh


    Use .config/rpi-cirrus-config.sh.sample as a template. This scripts makes use of a bunch of helper functions and definitons in /usr/lib/alsa/rpi-cirrus-functions.sh to simplify setup - you can either use these functions or simply add amixer statements as before (but note that you need to change the soundcard name).

    Note: These builds use the rather new Linux kernel 4.9. The current LibreELEC alpha builds also use this kernel but it's still possible that there are some (yet unknown) issues. Just drop me a line if something doesn't quite work as excpected.

    so long,

    Hias

    This script is only run during bootup. After that you'll get any signal that's present on LineIn to your speaker - if your TV (I assume lineout of the TV is connected to linein on the Cirrus card) outputs a transient on powerup/down you'll hear that - not nice.

    There's not much we can do to avoid this, except manually muting the signal or manually switching between "output kodi sound" and "output line-in sound".

    You could do that with the help of some external shell scripts (with mixer settings) that you then call from kodi - for example mapped to some buttons on your keyboard or remote.

    Calling a shell script from within kodi is a little bit tricky, System.exec doesn't work as expected (it messes up AudioEngine), you have to use Runscript to call a python script which then can use os.system to run the shell script. Look here for more info: LibreELEC

    so long,

    Hias


    There is one small problem outstanding; every time I switch on TV on switch the inputs, there is a loud switching noise (like popping or sharp loud tick sound). This only happens during switching. I tried 'Speaker Digital Switch' off, but the noise is still there. Any ways to mute that?


    When did you try the Speaker Digital Switch off setting? Right before switching on the TV?

    The "Speaker Digital Switch" control is the mute-control for the Speaker output. If it's set to off you shouldn't get anything on speaker output.

    so long,

    Hias

    Hi Vijay!

    Your listen script contains DOS lineendings (CR+LF), change that to unix EOL style (LF only). Ah, and better use #!/bin/sh instead of #!/bin/bash.

    You also have to reorder the scripts in the udev file, currently Playback_to_Speakers runs after your Listen scripts and resets the Input 2 settings.

    It's best to merge that into 1 single file, setup Input 1 to AIF1RX1/2 and Input 2 to IN3L/R

    so long,

    Hias

    Have a look at the Listen_to_LineIn_on_Speakers.sh script as an example of how this can be configured. But note you can't use that script out of the box, it also uses Input 1 of the speaker output mixer (same as the playback to speaker script).

    It's best to copy the Playback_to_Speakers.sh script to the storage partition, let's say /storage/speaker-setup.sh and make some alterations. You probably also want to change the volumes of Kodi audio output, the signal received on line-in and the speaker output volume.

    First, route the line-in signal (IN3L/IN3R) to the second input of speaker out, using the default input gain of 0dB (input volume 32)

    Code
    amixer cset name="SPKOUTL Input 2" IN3L
    amixer cset name="SPKOUTL Input 2 Volume" 32
    amixer cset name="SPKOUTR Input 2" IN3R
    amixer cset name="SPKOUTR Input 2 Volume" 32

    There are several knobs to turn to control the volume. Let's go input-to-output:

    "IN3L Volume"/"IN3R Volume" control the analog input gain (before the ADC). Default is 0 (0dB), 1 is +1dB etc. Usually values between 0 and 8 should be OK (depending on the analog signal level).

    "IN3L Digital Volume"/"IN3R Digital Volume" control the gain in the digital domain (after the ADC). Usually it's best to keep that at the default 128 which means 0dB (i.e. no volume change).

    "SPKOUTL Input 2 Volume"/"SPKOUTR Input 2 Volume" set the output mixer level. Default is 32 which again means 0dB (31 is -1dB, 33 +1dB etc). Adjust these and also the "SPKOUTL/R Input 1 Volume" (RPi/Kodi volume) settings so that the line-in signal and kodi signal are about the same level. But be careful: if you set it above 32 the signal might clip (especially for Kodi output).

    "Speaker Digital Volume" sets the speaker output volume, that's your "master volume knob". Default is 128 / 0dB, 127 is -0.5dB etc. Again, better only use values lower or equal to 128 to attenuate the signal, values above 128 may cause clipping.

    so long,

    Hias