Posts by chewitt

echo "options em28xx card=92" > /storage/.config/modprobe.d/dvb.conf

That ^ would test the suggestion from one of the GitHub issues.

I wouldn't advise a direct update from LE 9.2 to LE 12 as the Python2 to Python3 change often causes crashing and issues that some users find challenging to self-recover from. Instead I would download the update .tar to /storage/.update and then stop Kodi and rename the /storage/.kodi folder to /storage/.kodi-old and then reboot to start the update. This will give you a clean LE12 install. Then it's a simple case of stopping Kodi and copying the essential bits of userdata config back (sources, addon preferences, passwords, DB files, thumbnails) before restarting Kodi.

reading s905_autoscript
reading KERNEL
reading uEnv.ini
reading /amlogic/meson-gxl-s905d-sml5442tw.dtb
load dtb from 0x1000000 ......
      Amlogic multi-dtb tool
      Single dtb detected
find 1 dtbos
dtbos to be applied: 0
Apply dtbo 0
   Uncompressing Kernel Image ... OK
   kernel loaded at 0x01080000, end = 0x02958a00
   Loading Device Tree to 000000001fff2000, end 000000001ffff01f ... OK
Starting kernel ...

I stripped the noise out to show the essentials. It looks good to that point, and there's nothing more recorded except

bl31 reboot reason: 0xd
bl31 reboot reason: 0x0
system cmd  1

It's rather nice to see one of these boxes "in the wild" .. I only have a couple of pre-release samples shared by an O2.cz product manager we met during the Embedded Linux Conference in Prague back in 2017

Can you share the UART/boot output from Armbian? .. I'll see if I can spot any differences.

S905-H is an S905 chip with DTS license, and rev C is the same silicon revision as WeTek Play2 (and many other boxes). If you have been using older LE/CE images on the box you MUST force recovery boot so the device reads the u-boot boot scripts from the SD card, else u-boot is looking for the wrong filenames. It should boot using meson-gxbb-p200.dtb.

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.