Thank you for looking into my issue.
With the current latest version (RetroELEC-RPi2.arm-9.1-devel-20190825190342-c79d262.img.gz) I see the same crash in dmesg.
Logs removed
Posts by RomMon
-
-
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.
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...)
-
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.
-
How do you update from previous version?
You are on a version that already support the new zstd compression for the squashfs, so you can just place the .tar or img.gz in /storage/.update/ and reboot.
(For others, if you are on a regular LE version you need to follow the readme on the Google drive from post 1!!!!)
-
Will you still compile/upload a cherrytrail optimized image?
-
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):
Codespeaker-testIf 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.
-
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:
Code
Display More# /usr/bin/sdl2-jstest -l Found 2 joystick(s) Joystick Name: 'PLAYSTATION(R)3 Controller' Joystick GUID: 050000004c0500006802000000800000 Joystick Number: 0 Number of Axes: 6 Number of Buttons: 17 Number of Hats: 0 Number of Balls: 0 GameController: not a gamepad -
@TheCouchMonster
Must be another problem than I had.
I was running the same old version as you did (20170621) for a long time without problems.
It is a change in kernel-modules for Sony used in the current versions requiring remapping for DS3/4 controllers. See #1,978, and #2,013
But there is something causing difficulty configuring RetroArch in current versions, a RA bug according someone #2,063.
-
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.
-
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:
Codedocker 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 -
I'll try to remedy the Spotify issue in the next build.
Great Thanks!
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 directoryFull 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.
-
Can you have a look at this earlier post about Spotify not stopping after quitting with [ALT]+[ESC]?
