Posts by ppehrson

    Thanks for your answer!

    Yeah, I don't need it, I just wanted the notifications (which I have connected for "healt_h issues" through Telegram) to stop.

    Regarding your Windows comment, according to the wiki:

    Alright, so... I actually made it work this way:

    In /storage/.kodi/addons/service.lidarr/bin/lidarr.ctl,

    add this line after the export that's aldready in there:

    export PATH="${ADDON_DIR}/bin:$PATH"

    I am not sure if this runs on every boot / service startup.

    But you can also add this to /storage/config/ so that it executes on boot:

    export PATH="/storage/.kodi/addons/service.lidarr/bin:$PATH"

    so it should become like this:



    (sleep 3;

    export PATH="/storage/.kodi/addons/service.lidarr/bin:$PATH"

    # whatever other commands you might have in there



    Copy fpcalc (I got it for x86_64 from the Chromaprint package) to /storage/.kodi/addons/service.lidarr/bin and give it executable permissions.

    Start Lidarr.

    This works well for me.

    An alternative is to mount / as writable, copy fpcalc to /bin and that will work right away. BUT that may (will probably) be overwritten on system update.

    fpcalc is part of the libchromaprint-tools package, which is not included in libreelec.

    So audio recognition will not work until the executable is included in lidarr with a location fix.

    A workaround is to mount / as writable and create a link in /bin to where you placed the fpcalc executable.

    I am most surprised though that a Mono application is written to rely on a OS-specific package. How does Lidarr work in Windows then?

    I would just leave it off. It's pretty resource intensive and practically useless, except for audio verification (and you can probably verify if a song is the wrong one, anyway)


    On x86_64, with LibreElec 9.80, I had an error when trying to start Bazarr on the latest nightly (LibreELEC-Generic.x86_64-9.80-nightly-20210114-4493a6b)

    This might be an issue for earlier releases, as well.

    Bazarr would not start due to a numpy error with one of the numpy libraries (numpy.libs).

    The reproduction is to simply install a recent LibreElec 9.80 distribution and adding the repository thoradia

    I fixed it this way:

    I installed pip and numpy (with some trouble) and replaced numpy and numpy.libs in the Bazarr package. This made Bazarr work again.

    What I did was simply bump numpy and numpy.libs to v1.19.5.

    I have prepared a package which should replace the ones in /storage/.kodi/addons/service.bazarr/libs/libs/numpy.libs_old (again, for x86-64).

    You can get it at

    That was the old way, now I extract them from LE image using 7zip.

    OK, but then you have to know exactly which sub-version of LE includes those exact libs. I think it's easier to find them for Ubuntu. Or, compiling them with the right version's source.
    Of course, there's the hassle with renaming each lib, since RA looks for the major version and on Linux the major versions are just links to the minor versions.

    Now, another issue.

    If I run a game with EmulationStation, it reverts to ES.

    If I run the commandline manually, I get a regex error:

    # /storage/.kodi/addons/game.retroarch/addon.start mame2003 /storage/emulators/roms/mame/ ES
    sed: bad option in substitution expression

    Also, EmulationStation doesn't find anything to scrape (MAME).

    When hashing the code that throws the sed error out, retroarch_debug.log shows that a segmentation fault is thrown.

    This doesn't happen when executing a game in RetroArch, which works flawlessly.

    OK, so I have compiled a set of extra libs that are required for 1.7.4 to run on LibreElec 8.90.005 (though only for Gen, since I don't currently have my Pi running).

    1.7.4 requires 109 MB of libs to run. It works! - but there are some black squares on some menus where icons are supposed to be. I am not sure why this is; I just copied the binary and all the 85 required libs, so maybe I am missing something. (Edit: I have the original deb archives in tar format, there is an asset directory which is supposed to be in /usr/share/libretro)

    You can get it here:

    BTW, I was right. LibreElec is compatible with Ubuntu 16.04.

    To run it using SSH you should call or directly this command "sh ./ retroarch" (note that you need to specify name of the addon after file)

    I personally have all my romset collections in an external HDD with my movie and music collections pluggedto my RPi just when I want to play sometihng, and I use AEL to launch them from kodi, but I think every user has each own way to short his/her collection ;)

    OK, so there was an explanation.

    Yeah, I used to use OpenElec where I had them split into subfolders under Emulators, I think I ran them from within RA.

    Pls read my above post if you need help with updating RA to newest (it looks promising)

    It is now running if I start it from within LibreElec.

    It doesn't start if I run ./ from SSH (not that this is important)

    I haven't yet tested functionality (mainly MAME) since I need to figure out how to organize the collection (it doesn't seem smart to put all roms in Emulators/roms on LE, due to different architectures.

    How do others do this?

    PS: As far as I can remember, OpenElec shared binaries with Ubuntu, but I don't remember which version. Maybe it's the same with LE, which will make it pretty easy to update the binaries.


    This actually seems to be working, getting RA thru the official deb src, but it wants other libraries: => not found => not found => not found => not found => not found => not found => not found => not found => not found => not found => not found => not found => not found => not found => not found => not found => not found => not found => not found => not found => not found

    If you wish, I could gather them and test further and then send them to you.

    I am testing this with Bash on Ubuntu for Windows (which is current).

    It's possible to play Netflix on an RPi3 (3B+ is better) but not more than 720p resolution as video is software decoded. It's best to mildly overclock the RPi to improve the CPU performance, and install a heatsink to help with cooling.

    That's my point. The NUC is only a bit more expensive and does this, and also H.265 without any issue up to 4K. Even the Celeron.

    Not all NUCs are likely to support HDR, only the more expensive Core iX variants, and not the Pentium or Celeron chips.

    The current Celeron-based NUCs certainly do support HDR.

    NUC6CAYH - HDR? |Intel Communities

    It is now missing and two other libs (see below), but it doesn't error with the others anymore.

    I tried linking to the available libs, but this doesn't work since their major version is changed.

    To help you with the exact necessary libs, here are the remaining missing files according to ldd: => not found => not found => not found

    Thanks in advance :) - I am not sure where I should get the libs, as I don't know which Linux flavour LE is built on.

    I am sure adding these last files will fix the issue.

    I logged it on Github, just to make sure it is seen :)

    The current build of Retroarch does NOT work with the current LibreElec 8.90.005 (on x86_64)

    It exits with errors, and I found these missing FFMPEG and general libs by running "ldd game.retroarch-Gen": (58.18.100 is in libreelec) (58.12.100 is in libreelec) (56.14.100 is in libreelec) (2 is in libreelec) (5.1.100 is in libreelec)

    Intel NUC, guys. Why buy a smaller-footprint RPi which costs almost the same but requires tedious work to get to work right, has other limitations, and runs ARM, when you can get a mini x64-based board for almost the same price which has NO problem with 1080p, 4K or 3D?

    In addition, you can attach anything and it will make use of it - even a USB tv-dongle.