RPi4 on LE 9.2 has a 64-bit kernel and 32-bit userspace so that's not the problem or the solution. I'd suggest starting with an update to LE 11 or an LE 12 nightly to avoid all the issues found/fixed since the last LE 9.2 release (around two years ago).
Posts by chewitt
-
-
I'm not sure if that's an error about finding libpcloudcc_lib.so or libpcloudcc_lib.so is dynamically linked against other things which are missing and thus it fails to open the file which it found. There's no harm in experimenting with LD_LIBRARY_PATH so give it a try. You can also share the output from "ldd /storage/backup/libpcloudcc_lib.so" to see whether it's linked against anything missing.
-
Have you tried copying the existing binary over to /storage and see if it runs?
-
I just need confirmation from someone with an rpi and LE 11 so we can make sure it's not specific to amlogic.
All my things are updated to LE12/aarch64 so not volunteering to test .. but there's nothing special about the AMLGX image; it's functionally the same as RPi4 and other SoCs like Allwinner.
-
Quadro P400 (2017) is not the same as Quadro 400 (2011)
-
There are several reasons:
a) Kodi no longer supports OMXplayer and MMAL decoding as part of the general move to drop all proprietary codecs to focus on modern kernel standards (GBM/V4L2).
b) The Pi graphics pipeline in the newer kernel used by LE10 has been rewritten around modern kernel standards (GBM/V4L2) so "assisted" decoding would need to be reimplemented from scratch in both kernel and ffmpeg. The original patches amount to 100,000 lines of code and authoring that (and then maintaining is downstream) is a large effort.
c) Only a couple of distros (mainly LE and OSMC) have been daft enough to allow 100,000 LOC patches into their codebases so the audience that would benefit from a large reimplementation effort in 'B' is small.
d) RPi4 and up support hardware HEVC decoding (although to be clear, forcing hardware upgrades on users has never been a goal). It does mean over time the issues reduces in size along with the RPi2/3 user population.
e) Nobody is forcing users to update from LE9.2 which continues to have the feature.
-
-
May be its worth to give nvidia a hardware menu entry.
Like this? https://libreelec.tv/downloads/generic/
Wiuth old cards like a Quadro 400 (2011?) you'll need to compare the card PCI device ID with the nVidia udev rules to see if it's supported:
LibreELEC.tv/packages/x11/driver/xf86-video-nvidia/udev.d/96-nvidia.rules at master · LibreELEC/LibreELEC.tvJust enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.github.comOne of several challenges with nVidia support is that compat with Xorg is a moving target and eventually old(er) driver releases that are no longer actively maintined by nVidia require older Xorg versions than the current Xorg that we embed and things break. See:
xf86-video-nvidia: update to 535.104.05 by heitbaum · Pull Request #8090 · LibreELEC/LibreELEC.tvMajor Bump of nvidia Update from Latest Legacy GPU version (470.xx series): 470.199.02 to Latest Production Branch Version: 535.104.05…github.comYou could try using an older LE release (older Xorg codebase with older drivers) or to use a more general purpose distro where things are less bleeding edge and you can still load and use older nVidia drivers.
-
NB: I deleted the other thread with identical question. Post questions once only please.
-
RPi4 can power off via scripted keyboard commands, but you cannot power on via the flirc USB receiver as the RPi4 board (when off) does not power the USB ports to receive the IR wake signal. The normal way around this with Pi 0/1/2/3/4 hardware is to have a power-board with IR sensor connected to the GPIO pins. The IR sensor is powered independently so can receive a wake command and then power-on the board via the +5v/GND GPIO pins not the normal USB-C connector. In that setup the Flirc USB receiver is redundant since you now have a permant IR sensor on the board.
RPi5 should in-theory be able to do the USB-wake scenario as the RP1 and BCM2712 chips have the combined capability to support low-power states like 'suspend' where selected subsystems remain powered-enough to receive input and wake up again (as with some x86_64 hardware or Android boxes). The caveat is that this support requires firmware which is both complex and still actively being written (work in progress) so if you pre-ordered an RPi5 board today there's no guarantee that will work OOTB when boards ship or for some time after. It's definitely something that Pi devs are exploring and working on though.
-
https://wiki.libreelec.tv/hardware/intel…ric#nvidia-gpus <= The info here is a little dated in a couple of places, but the fundamental underlying message remains the same (for a long time).
-
-
Are you using the Generic Legacy image? The default (GBM) Generic image no longer contains nVidia drivers due to their lack of support for modern Linux graphics standards.
-
Unless you have a fast Intel CPU device; leave it at the default (1080) setting.
-
Mi Box S Gen 2 uses an S905X4 chip and the mi stick 4K is either S905Y4 or S805X2; in all cases there is negligible usptream kernel support for those chipsets so no current plans for LE support. If the bootloaders are unlocked you can probably get CE to run on them, but that's a topic for the CE forum not here.
-
IMHO wait until the RPi5 bits arrive then pull the drive out and connect to the new(er) RPi5 based NAS device. As much as I like the Slice box it's slow and dated and having the drive connected locally to the new stuff will just be easier.
-
Please report this to the add-on support thread in the Kodi forums; then someone might make changes to correct the issue upstream.
-
I'd suggest updating to a current LE12 nightly (which are quite stable to use) as a first move. Then if the issue is still present, share a sample (90-120 seconsds) from a media file that allows the issue to be recreated. Then pi devs can have a look.
