Posts by chewitt

LE is almost certainly not "freezing at the splash screen" .. but something prevents it from being able to correctly setup an output display device and thus the boot splash is never overwritten by the Kodi desktop appearing. I have a hunch this is related to EDID data on the HDMI connection (or lack thereof) but a debug log from the RPi will normally allow us to see if that's the issue.

I'd guess the BIOS is preconfigured for Windows and you'll need to disable EFI secure boot or allow legacy boot modes.

I'd guess the Windows drivers understand how to route audio signals to the DVI interface, and the Linux display drivers do not have the same capabilities; which is somewhat understandable as DVI hardware is not normally carrying audio signals.

Please provide the debug log previously asked for. Also run "amixer contents | paste" and share the URL generated so we can see the audio mixer control options and settings.

Quote from Frimelbear

is there a way to work with the toolkit and scriptset which creates Libreelec to create my own version?

You'd have to add python modules and whatever scripts are required. It's possible, but there are no instructions, although the buildsystem contains a large amount of prior art.

Quote from ararTP

Also, I can't install the certificate from the chrome settings, when trying to choose the file, chrome crashes.

Chrome is probably trying to access an internally hardcoded path that either doesn't exist in LE, or perhaps expects rw access and the path is inside the ro filesystem. As we don't compile Chrome for LE that can't really be changed.

No idea why it doesn't use the system cert chain either .. just commenting on that ^

The Terramaster box doesn't support hardware RAID so I think you created a "Spanned Volume" over the two drives. This uses the Logical Disk Manager (LDM) capabilities which are not natively supported on Linux, although there is a tool called "ldmtool" which can be used to create device-mapper entries and mount volumes. However, LE does not bundle ldmtool into our images, we do not support package management, and we are intentionally missing all the software RAID and device-mapper bits (so we don't have to support it).

This community image from sky42 has the LVM bits you need LE 12.0 added lvm2, luks (dm-crypt, veracrypt), mdraid, ext4 encryption .. but not ldmtool AFAICT. You can try copying the ldmtool binary direct from an Ubuntu image; if you're lucky it's an independent binary that's not linked against a bunch of libraries. If you're not, it is, and it needs to be compiled properly for LE use. That image also has the bits needed to make a Linux compatible software RAID (JBOD) setup; though that will require you to move data off the disks to create a new JBOD array before copying data back.

Of course, even if you make something work, it's not supported by staff.

Quote from squirtbrnr

So are my options either to buy an external HDMI video capture hardware device to run boblight, revert back to an LE9 install with OMX/MMAL, or buy a device other than an RPi with built-in hardware decoding to run LE?

LE uses GBM/V4L2 rendering on all hardware these days and there's no support for that method in any of the ambilight/boblight type applications (and no signs of that changing). Sticking with LE9.2, or using a hardware grabber, are the only options.

AirPlay target is a Kodi feature so how it works is internal to Kodi. All we do is bundle the required lib, there's nothing that you can configure on the LE side.

In short, no.

You have banned add-ons installed. Your problem is not our problem.

Official:Forum rules/Banned add-ons - Official Kodi Wiki

Quote from osen

Can I just add the following to uboot_helper

Yes, correct.

Quote from osen

And then build using the command PROJECT=Rockchip ARCH=arm DEVICE=RK3399 UBOOT_SYSTEM=rock-4se make image ?

Yes, correct, except for "ARCH=arm" because with LE12/LE13 sources you should be using "ARCH=aarch64" now.

Hopefully upstream devs have already done whatever u-boot juju is needed to get a working image. Good luck

Can you provide a Kodi debug log from clean boot while demonstrating the problem? - I doubt there's anything useful in the log, but you never know. NB: I've never tested the AMLGX image with S/PDIF output (as I no longer have anything that accepts S/PDIF input) so i'm a little blind on how it performs.

LE boots the KERNEL file and the kernel init script mounts the squashfs SYSTEM which results in a virtual and intentionally read-only filesystem, so the /etc folder is not writeable and cannot be made writeable from within the running OS (as the file is in use).

It is technically possible to have the kernel init mount the squashfs SYSTEM file read-write; but that requires you to modify the init script embedded in the KERNEL file and that's only possible by creating your own LE image with changes (it's intentionally not configurable). Similarly you can mount the squashfs SYSTEM file read-write from another Linux device to make changes inside. It's fiddly and fine for test changes, but in the long-term maintenance updates will overwrite the changes you've made so if something must be modified over the long-term you'll need to investigate creating your own image again.

Most things that users might need to change in /etc have config or override methods from /storage/.config .. but it's not 100% of things so some changes might still require you to self-build an LE image.

TL/DR: It's probably better if you explain exactly what you want to change/edit, then we can be more specific with answers.

Have you experimented with the HDMI ports the device is connected to on the TV? .. On modern TVs they are not all equal.

I see transfers around ~112MB/s from an RPi5 with nvme storage.

I see transfers around ~33MB/s on an elderly Amlogic S905 box with emmc storage.

I see transfers around ~12MB/s on another Amlogic board booted from USB storage.

All three have gigabit NICs, but all three internally wire them up differently and storage media can have a large impact too.

The bluez.conf file is intentionally empty. If you want to start bluez with either BLUEZ_ARGS or BLUEZ_DEBUG variables defined; the variables go in that file. If the bluez.conf file is missing the bluez service doesn't start (as per the systemd service config). The sole purpose of it being created is to enable the service starting (same as for sshd, avahi, samba, etc.)

No idea what the issue with the soundbar is, but for the sake of creating a half-meaningful comparison; install RaspiOS on a spare SD card and see if that works. If it also fails at least things are consistent and that probably hints at something odd with how the soundbar responds to bluez. If it succeeds, it probably hints at software versions of bluez since I'd guess that LE is using a newer version than a general purpose distro. I might be wrong on that but it's often the case.

ilovebytes Just to confirm .. if you connect only GND, the device boots?