Posts by chewitt

I think the settings add-on stuff was removed around 9.0 or 9.2 as it wasn't really needed. These days we detect /storage/.config/lircd.conf (via lircd.service) which runs a helper looking for /storage/.config/lirc_options.conf before executing /usr/sbin/lircd .. no conf files = no need to start lircd (only eventlirc).

Quote from 13lenar

in LibreELEC (Matrix) 10.0.0 the solution does not work

I've used the capability to overlay firmware files for testing on a Cubox-i image within the last week, so I disagree. Pastebin directory listings to prove you did things correctly.

You need to self-compile the entire distro (image) from sources. Read: https://wiki.libreelec.tv/development-1/build-basics

Make sure you restore fluxbox too.

RPi4 will report as BCM2835 due to compat decisions in the kernel code and depending on what's been queried from userspace. It's not a fake RPi board, it's normal. See some older explanations for RPi3B reporting the same way (it's still the same thing):

RPi 3 with BCM2835 ??? - Raspberry Pi Forums

RPi 3 with BCM2835 ??? - Raspberry Pi Forums

AppleTV (mk1) uses "atvclient" to process events from the receiver, see GitHub - chewitt/atvclient: AppleTV Remote XBMC Event Client for Linux .. but we dropped the package from LE several years ago now. It's my understanding that the kernel should be able process the events via USBHID, but you will need to use LIRC which is disabled by default. I'm not very clued up on LIRC usage, but https://wiki.libreelec.tv/configuration/…es#lirc-support and iMacIntel - Debian Wiki might give some hints on what to do.

LE will boot with a 32MB /storage partition - no files are copied and *everything* is in the read-only squashfs SYSTEM file.

Some of the changes in distributions/LibreELEC/options will cause problems for a Generic build add ATV project/patches and adjust distro options · chewitt/LibreELEC.tv@ca3ee28 · GitHub

blackride I looked for hardware differences odroid-c2:hardware:hardware [ODROID Wiki] but HK fiddled with USB a little (the weak part of their designs on multiple boards) but I don't see anything that would impact an SD card. If there were meaningful differences in the dtb files I'd have something to go on .. but both of the visible changes are minor things. As for the future of LE10 .. I keep what does work rebased against LE in the hope people who develop code take an interest, and I do device-tree work to add support for hardware into the upstream kernel, but Amlogic media capabilities in the upstream kernel are not in brilliant shape and I don't code so have limited ability to fix anything. LE releases don't make much sense right now (which is why nightlies are stopped and we are not pushing it at anyone). Maybe things change. Maybe they don't. The future is up to the community..

kenmills You will need to use the images under my share as there are no project nightlies right now. You can use rufus or other SD writing apps like Etcher. If the box needs the toothpick method .. use the toothpick method (this varies by box). Use the "box" image and configure a device tree filename in uEnv.ini that is similar to your hardware; there are some other GXM box devices that are probably a close match.

Sep 14 00:37:53 LibreELEC xorg-launch[563]: gbm: failed to open any driver (search paths /usr/lib/dri)
Sep 14 00:37:53 LibreELEC xorg-launch[563]: gbm: Last dlopen error: /usr/lib/dri/i915_dri.so: cannot open shared object file: No such file or directory
Sep 14 00:37:53 LibreELEC xorg-launch[563]: failed to load driver: i915
Sep 14 00:37:53 LibreELEC xorg-launch[563]: gbm: failed to open any driver (search paths /usr/lib/dri)
Sep 14 00:37:53 LibreELEC xorg-launch[563]: gbm: Last dlopen error: /usr/lib/dri/kms_swrast_dri.so: cannot open shared object file: No such file or directory
Sep 14 00:37:53 LibreELEC xorg-launch[563]: failed to load driver: kms_swrast
Sep 14 00:37:53 LibreELEC xorg-launch[563]: gbm: failed to open any driver (search paths /usr/lib/dri)
Sep 14 00:37:53 LibreELEC xorg-launch[563]: gbm: Last dlopen error: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory
Sep 14 00:37:53 LibreELEC xorg-launch[563]: failed to load swrast driver
Sep 14 00:37:53 LibreELEC xorg-launch[563]: couldn't get display device

^ It cannot load the Intel i915 GPU driver and also fails to fall-back onto swrast. So what GPU is in the laptop?

"journalctl | paste" .. Kodi logs aren't much help (and it's not debug level)

Hauppague made a big effort to upstream their drivers in recent times, which reflects in ease of support. TBS are still in the raised middle-finger zone.

"cat /path/to/log | paste" should do the same, although I forget what paste service was used in 7.0 days

You can disable removable drive auto-sharing in the LE settings add-on under Services > Samba. You should not fiddle with the content in the .cache folder as the settings add-on expects exclusive access (the folder is hidden for a reason).

No idea what the issue might be with graphics, other than "device is too old and GPU not supported" .. but get access via SSH and share logs and we can see more what is happening. SSH is disabled by default (can be enabled in the GUI first-run wizard) but it can be forced with "ssh" in syslinux.conf boot params.

Did you run "PROJECT=Generic ARCH=i386 make image" ??? .. it should create .tar and .img.gz files. The .system file is "SYSTEM" not a full image (hence it does not boot/work).

Even if you solve .mxf format detection in Kodi, an RPi4 cannot hardware decode 4K H264 media (the H264 IP block is the same as an RPi3Bs and it supports only up to 1080p) and it will not have the CPU grunt to handle software decoding gracefully. Your best option is to use an app like Handbrake to re-encode the files to 4K HEVC (8-bit) which is supported. If you can change the camera to use HEVC instead of H264 you can skip this step in the future. NB: OMXplayer exists in LE 9.2 images as an alternative to MMAL decoding for older RPi devies. OMXplayer support was removed from Kodi 19 so it is not present in LE10 images. It is not the solution, because no RPi device supports 4K H264 hardware decode.