Posts by HiassofT

  • speeding up build process (make -j?)

    The build should automatically use all available cores.

    You can manually configure the number of parallel processes by setting the environment variable CONCURRENCY_MAKE_LEVEL (eg to 8).

    Also note that for a few packages parallel build is disabled as it doesn't work reliably (for example busybox).

    LTO also increases build time (and for most packages linking with LTO only uses a single core), so you could try setting LTO_SUPPORT="no" in ~/.libreeelc/options - but note this isn't always fully tested and building without LTO can sometimes result in link errors. PRs to fix this (mostly missing -fPIC options in libs) are welcome, though :)

    so long,

    Hias

  • Allo Digione

    If the card doesn't have an eeprom with the dtoverlay (so it's automatically enabled) you could try adding this to your config.txt (remove the old dtoverlay=hifiberry... line first)

    Code
    dtoverlay=allo-digione

    so long,

    Hias

  • VS1838B does not work in raspberry pi (SOLVED)

    There's not much info about the VS1838 except for a chinese datasheet and some posts stating that the Vishay (TSOP) receivers perform better.

    One thing you should check is that you have proper filitering on the IR receiver's VCC pin. The datasheet shows a 100uF capacitor in parallel to a 100nF - which usually should be soldered very near to the receiver. A 100 ohm series resistor can further help reducing noise on the VCC line. From the datasheet it's not clear if this is needed, but as noise on the VCC line can impact performance it won't hurt if you added that filtering.

    Personally I have only used Vishay parts so far, the well known TSOP34438 should do fine. I'm currently using the older TSOP34138 receivers here, which uses an older AGC version (1 instead of 4, the latter is recommended by Vishay for NEC and RC-5/6 remotes).

    So far I didn't have VCC noise issues with these receivers. The receivers are connected via approx. 0.5m long shielded cable and I haven't soldered filtering caps to the receiver.

    so long,

    Hias

  • Raspberry Pi 3 B+ reboot problems

    The issue seems to be a race condition in the ethernet driver when shutting down the network interface. This class of issues is one of the nastiest as it depends on exact timing if you hit the issue or not - and for that reason they can be extremely hard to reproduce.

    Simply speaking: it's rather random of the issue shows up or not.

    You don't need to spend more time on that, I managed to find out what's happening and why.

    A possible solution for the issue is already on the horizon, but it could take a bit until the fix is finished and added to the driver.

    Details of my analysis are in this RPi kernel issue: oops in lan78xx_delayedwork on kernel 4.9 when rebooting · Issue #2467 · raspberrypi/linux · GitHub

    so long,

    Hias

  • Raspberry Pi 3 B+ reboot problems

    I've seen this happen 2 or 3 times as well but it was rather hard to reproduce - most of the time reboot worked just fine.

    I just managed to reproduce it and capture the kernel output - it seems to be a bug in the RPi3B+'s ethernet driver which let's the kernel crash.

    I'll try to dig into that a bit and see if it's a general problem with the RPI3B+'s ethernet driver or something specific to LibreELEC.

    so long,

    Hias

  • 8.2.4 MR audio issue

    grael

    Do you get the same issue when using the newer firmware on 8.2.3 builds?

    Do you have Resample Qualtiy set to "GPU accelerated" in Settings->System->Audio (settings level must be advanced or expert to see/change that)?

    Does it go away when changing Resampling Quality to Medium or High?

    so long,

    Hias

  • Sharp IR Remote on Intel NUC 2820 double presses

    Wow, thanks a lot David, this must have been the most detailled bug report I've received here so far! And it contained more than enough info to reproduce and understand the issue.

    The problem stems from the combination of using a Sharp remote with an ite-cir receiver. The Sharp IR remote messages are rather long (about 86ms in the sample you provided) and the default idle timeout of the ite-cir driver is also rather high (200ms). So what is happening is that when you release the button (no matter if it's a short or a long button press) the sum of that - 286ms - exceeds the default kernel "key release" timeout of 250ms - and the last message (which is delayed to the timeout) is seen as another button press.

    With other remotes, like for example MCE remotes, this does not occur because the sum of message time (about 40ms in case of rc-6 MCE) and 200ms timeout is just below that magical 250ms limit.

    I've recently discussed these issues with long timeouts with the kernel developer and hopefully there'll be a good solution in the future - it could take a bit, though, it's all a bit tricky.

    Fortunately, there's an easy workaround you can use for now, you can manually configure the driver to use a lower timeout. The minimum timeout of ite-cir is 100ms, I'd use that and if that causes other problems I'd try a bit longer values (125-150ms).

    You can set the timeout with ir-ctl -t TIMEOUT, but keep in mind that ir-ctl expects the value to be in microseconds, not milliseconds. So use eg "ir-ctl -t 100000" to set a 100ms timeout. You can either add that to autostart.sh or add an udev rule for that. I've posted info how to do that in the Amlogic IR remote thread here: LE9.0 remote configs ir-keytable Amlogic devices (replace "meson-ir" with "ite-cir" to make this work).

    With the rather long messages you could run into key repeat more easily, you can change that with "ir-keytable -D DELAY" - that's the delay before repeat starts, default is 500ms. Ah, and here the delay is in milliseconds, so use eg "ir-keytable -D 700" to use a slightly longer delay.

    so long,

    Hias

  • Changing from RPi 2/3 to RPi 3B+, FIRST upgrade to 8.2.4 (including NOOBS instructions)

    There is be a problem if you are using NOOBS. Updating LibreELEC is not enough, you also have to update NOOBS before the SD card will boot in a RPi 3B+.

    I've found instructions how to update NOOBS here Updating Raspbian on your microSD for the Raspberry Pi 2 – The Pi Hut and successfully tested this with a NOOBS 2.4 installation.

    1. Download NOOBS LITE v2.7 (not the full version, the LITE one) from Download NOOBS for Raspberry Pi
    2. Extract the ZIP file and copy all files EXCEPT recovery.cmdline to the first partition of the SD card

    You can either do this on your PC or with the following commands from within LibreELEC:

    so long,

    Hias

  • Raspberry pi firmware update

    The firmware is included and updated with LibreELEC updates and usually there's no need to do that independently from that.

    If you really want you can update the firmware files manually, at your own risk:

    Download bootcode.bin, start_x.elf and fixup_x.dat from the RPi firmware github repository, rename start_x.elf to start.elf and fixup_x.dat to fixup.dat and copy the 3 files to the /flash partition.

    You can also easily do that from Windows/Mac/Linux (can be helpful if you messed it up) as the /flash partition is FAT formatted.

    so long,

    Hias