Posts by RomMon

    @escalade

    I'm creating a new setup on a 2nd hand 'Tronsmart Ara x5 plus'.

    (started to miss my HTPC too much)

    I do have an error if I try to setup Weatherbit.io.

    Code
    /usr/lib/python2.7/site-packages/PIL/_imaging.so: undefined symbol: ZSTD_freeCStream

    (see details here)

    Is this something that you can help with solving?


    I'm glad that I have SABnzb, Plex server, and Kodi in general back again.

    TVHeadend is running fine(isch) via Docker with a few minor issues.

    Thanks for sharing new images.

    I tried the Kodi image (RetroELEC-RPi2.arm-9.1-devel-20190808003418-818ab9e.img.gz) on my RPi3b.

    It boots into an empty Kodi screen (just a background image).

    dmesg shows a crash.

    The attached logs are from all USB-devices disconnected, just HDMI and Ethernet connected.

    log-2019-08-17-13.12.23.zip

    Also tried the non-Kodi image (RetroELEC-RPi2.arm-9.1-devel-20190807233002-818ab9e.img.gz), and that looks to boot fine.

    From this thread I tried the 'LibreELEC-RPi2.arm-9.1-Milhouse-20190415220250-#0415-gbcf6a8e.tar' build, which also boots fine into Kodi.

    Edit (2019-08-18):

    Found the latest Kodi image (RetroELEC-RPi2.arm-9.1-devel-20190815154218-7e7bd3c.img.gz), and have the same issue.

    My Atom based Tronsmart Ara x5 Plus got fried by lightning. So I fall back to my RPi3.

    I tried to get image ‘LibreELEC-RPi2.arm-8.2-devel-20180218.img.gz’ working.

    It boots fine and it all looks to work normal, but unfortunately I don’t get TVHeadend to work.

    (also tried LibreELEC-RPi2.arm-8.2-devel-20171118.img.gz, same behavior)

    With LibreELEC-RPi2.arm-8.2.5.img.gz TVH4.2 is working.

    Is this a known issue? (I'm aware of the missing libs for the generic arch, that can be solved with simlinks)

    And is Plex Media Server suppose to work on a RPi?

    (attached logs just in case...)

    gwire

    Indeed via ssh.

    To find the location of the executable (script):

    which spotify

    To see if the file is an (executable) binary or (executable) script:

    (you already know it is a script, so text based, but just to let you learn)

    file /usr/bin/spotify

    To actually see the content of the text file:

    cat /usr/bin/spotify

    Have a good look at the script, to see if you understand it.

    The script contains two functions install_spotify and run_spotify.

    Below that you see two if fi blocks, a line that calls function run_spotify with some parameters. And next again a if fi block that only gets run if spotify has finished.

    It is the first two if fi blocks, and the call to function run_spotify that you need to understand and execute manually.

    @craigmillard

    I have not looked if my config contains sound config. If it does, it might be wrong for your hardware.

    Verify that first.

    Have a look at the first page, to be sure you don't miss anything.

    Kodi is using Pulsaudio, both RetroArch and EmulationStation are using Alsa (and so is Chrome and Spotify).

    (so if it works in ES it should work also in RA)

    Just to be sure:

    If you already did your alsa config you can perform a speaker test (it should give noise):

    Code
    speaker-test

    If there is no noise, you need to configure '/storage/.config/asound.conf' using the correct details from the 'aplay -L' output.

    Also mention your hardware details. Maybe someone with the same hardware can help.

    rooty

    Read first the readme on google drive (link from the first page).

    There are probably other ways to achieve this, but the following should work.

    - With the image from the archive folder on google drive (which is a .img.gz) you can create a bootable stick using the libreele_usb_sd_creator.

    - After installation of this image you can just transfer the intel-core-avx2 image from google drive to /storage/.update/, and reboot. Again read the readme in the avx2 folder on google drive to verify your hardware matches the image.

    Im having this same issue with a fresh install of LibreELEC-Generic.x86_64-8.2-devel-20171121!!:(

    Any tips to fix it, i can get the ps3 controller via usb to part work like RomMon but the guide in #2063 hasnt helped:(

    Im not using bluetooth here either..

    @craigmillard

    Indeed an annoying issue. The first time I tried #2,063 it worked flawlessly. Must be something small I did differently I suspect.

    I pasted my working retroarch.cfg config here

    And the udev config here

    File locations:

    ~/.config/retroarch/retroarch.cfg

    ~/.config/retroarch/autoconfig/udev/PLAYSTATION(R)3 Controller.cfg

    Maybe you should verify that your controllers are the same as mine:

    Ahaaaaaa. I had my two DS3 controllers working in RetroArch using LibreELEC-Generic.x86_64-8.2-devel-20171016 following #2,063. But after an downgrade/restore to LibreELEC-Generic.x86_64-8.0-devel-20170621, and upgrade again to Generic.x86_64-8.2-devel-20171016, I'm not able to get the DS3 controllers working in RetroArch...

    Tried following #2,063 again, didn't work.

    But even copying the following two files from a backup of the working situation doesn't help:

    /storage/.config/retroarch/retroarch.cfg

    /storage/.config/retroarch/autoconfig/udev/PLAYSTATION(R)3 Controller.cfg


    There is a change in controller behavior, where if I connect the DS3's with the RetroArch menu open it is continue scrolling down, and left/right of the D-pad is working. But the keyboard is not working while a controller is connected, and the other buttons don't work.


    Are there other files I need to restore?

    Edit:

    Copied over the two files again, and now it works. It is '/storage/.config/retroarch/retroarch.cfg' that made it work.

    @gwire

    Let me try to answer some of your questions.

    1. Start reading from post #1,884 for PS2 information. For logfiles, Samba should be enabled, so you can access the Samba shares from a remote location. E.g from a windows pc you can access the logs via: \\libreelec\Logfiles

    A script will automatically run to collect the required logs, and zip it for your. You only need to attach it to your post (no need for pastbin).

    Read the info and link in post #1 carefully.

    2. There are some tools installed with this build to test controllers, sdl2-jstest and hcitool. (I only used jstest)

    /usr/bin/sdl2-jstest -l (look for Joystick Number:, which can be 0)

    Dolphin has its own controller configuration, and you need to be aware of the option to toggle maximize/unmaximize a window with [ALT] + [F10]

    [Esc] > stop game and go to menu

    [F10] > resume game

    [ALT] + [F10] > toggle maximize/un-maximize a window

    Remove stats on screen:Options > Graphics > Advanced > Show Statics

    3. See 1.

    4. What do you mean. Do you hear menu-sounds, but would like to switch them off, or are you missing menu-sounds using a controller?

    I suspect the last one, as that is what I observe. Don't know, didn't check if there are options to have menu-sounds with a controller.

    5. The logs should help to find if the hardware is recognized. See 1. for logs.

    RomMon

    I can see just from your command line that you are using an ARM container on x86_64. Anyway, this is not a Docker support thread. I'll see about the qemu emulation issue at some point (could be my systemd version or recent kernel, it used to work), but if you have no specific need to run ARM binaries then you should use x86_64 containers.

    Ok, now I get it. I was just trying your command for 'Run Docker ARM containers on x86_64' from your post 1.

    The Portainer command is:

    Code
    docker run -d -p 9000:9000 \
            -v /var/run/docker.sock:/var/run/docker.sock \
            -v /etc/localtime:/etc/localtime:ro \
            -v /storage/.kodi/userdata/addon_data/docker.linuxserver.portainer/config:/data \
            -v /var/run/docker.sock:/var/run/docker.sock \
            portainer/portainer

    RomMon

    I'll try to remedy the Spotify issue in the next build.

    Great Thanks!

    RomMon

    As for the Docker issue, I'm not sure what's going on there. Are you by any chance using the Docker version that I had on my gdrive? If so, try using the official addon. Is there a particular reason you are using the ARM version of Portainer on Generic?

    I'm not using the Docker version from your gdrive, but the official add-on from the Kodi repo.

    The Portainer version is the one that got installed via LinuxServer.io repo (installed the linuxserver repo, next installed Portainer).

    How can I see if I'm using the ARM version?

    I tried Portainer on RPi3:

    • LibreELEC-RPi2.arm-8.2.0.1.img.gz > working fine.
    • LibreELEC-RPi2.arm-9.0-Milhouse-20171119210326-#1119-g26c5fad.tar > need to use the workaround from dan_jericho but fine after that.

    Tried Portainer on Tronsmart Ara X5 Plus:

    • LibreELEC-Generic.x86_64-9.0-Milhouse-20171119210325-#1119-g26c5fad.tar > need to use the workaround from dan_jericho but fine after that.
    • LibreELEC-Generic.x86_64-8.0-devel-20170621.img.gz > if I prevent the docker image from being updated it is ok, but once a new image is pulled I see the 'overlayfs: failed to resolve' errors in dmesg.

    Just tried upgrading to the Intel-cherrytrail image 'LibreELEC-Generic.x86_64-8.2-devel-20171116.tar', and also have the TVHeadend issue other mentioned.

    Code
    # cat ~/.kodi/userdata/addon_data/service.tvheadend42/service.log
    /storage/.kodi/addons/service.tvheadend42/bin/tvheadend: error while loading shared libraries: libva.so.1: cannot open shared object file: No such file or directory

    Full logs removed.

    Edit1 (2017-11-19): One of the Docker containers not running was Portainer. It looks something else is causing this. With restoring to my 2017-10-31 backup, and Internet disabled the container is running fine. But with Internet the image is getting updated (see ~/.kodi/addons/docker.linuxserver.portainer/bin/docker.linuxserver.portainer), and doesn't run anymore.

    Maybe related to??: LibreELEC Testbuilds for x86_64 (Kodi 18.0)

    /Edit1

    Edit2 (2017-11-19):

    Portainer is currently running ok(, using an older image). But still get the same error message for the Debian image.

    Code
    # docker run -it --rm -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static armelbuild/debian:jessie
    Unable to find image 'armelbuild/debian:jessie' locally
    jessie: Pulling from armelbuild/debian
    7c78e7488df7: Pull complete
    a3ed95caeb02: Pull complete
    8796be12624a: Pull complete
    Digest: sha256:dd3e2ffdceb98d84b6ac3419538e1ce92585543cbb9e1adee163bd33aef11b0e
    Status: Downloaded newer image for armelbuild/debian:jessie
    standard_init_linux.go:178: exec user process caused "exec format error"

    Uploaded a new log

    (removed)

    =================================================================================================================

    I have a problem with docker not running the containers.


    In dmesg I see some overlayfs failed to resolve messages, I'm not sure how they got raised, and how to solve them.


    From older dmesg logs I found the problem looks not to be present on 'log-2017-11-06-23.12.51_docker_ok.zip', but see these overlay errors in 'log-2017-11-12-10.21.11_docker_overlay_issue.zip', and later (both logs attached).

    forum.libreelec.tv/core/attachment/2320/

    forum.libreelec.tv/core/attachment/2321/

    Get the folliwing error if I try to run the Debian image included in this build:

    Code
    # docker run -it --rm -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static armelbuild/debian:jessie
     bash
    Unable to find image 'armelbuild/debian:jessie' locally
    jessie: Pulling from armelbuild/debian
    Digest: sha256:dd3e2ffdceb98d84b6ac3419538e1ce92585543cbb9e1adee163bd33aef11b0e
    Status: Downloaded newer image for armelbuild/debian:jessie
    standard_init_linux.go:178: exec user process caused "exec format error"
    #

    I will continue looking for the reason of these issue, but also thinging of restoring to my 2017-10-31 backups.