Posts by chewitt

Others might have tried but their labours would have been in vain. You'll need to clone LE to a case-sensitive Linux filesystem like ext4 to build a fully working LE image else the permissions of numerous critical system files in the image (if you even get that far) will be trashed and either the image won't boot or important services won't start. You'll need to use a Linux VM or container to build images; both of which should shield colons from the host OS. For the record, our 8.2 branch is no longer open to changes; only bumps to existing addons will be accepted.

LibreELEC is not based on buildroot so their packages will not translate directly. We loosely follow the recipe principles from Welcome to Linux From Scratch! but the main source of instruction is "prior art" in the current buildsystem.

The LED light ring should work "out of the box" in the LE 8.2.3 image. The only reasons I can think of for it not working are /flash/config.txt has been edited (or restored) to disable the slice overlay, or hardware was damaged while making the CM > CM3 upgrade.

C2's run best with the eMMC board.

Settings > Media > General > Allow file renaming and deletion

^ make sure that option is enabled.

Android device trees are not compatible with LibreELEC releases.

It's the correct product (there is only one kind of CM3 card) but you cannot upgrade using the Slice3 .tar file. CM3 requires a new install of LE 8.2.3 using the .img.gz file (mount the Slice storage on Windows or Linux and then use our USB/SD creator app to write the image) because the internal emmc storage is on the CM3 card; i.e. when you remove the CM(1) card you also remove the storage. It's not a big issue, just make a backup before you upgrade and then restore afterwards.

Your solution is a bit "wagging the dogs tail to make the head move" and it's years since I encountered a non-caching DNS server in a router so IMHO the correct solution is to disable logging in pi-hole so it doesn't fill the ramdisk, or change the location to somewhere with more space.

Probably not. Note that you will need approx. 2.5x the size of the backup file as free space on the SD card to restore successfully as the tar file and unpacked tart file will coexist at the same time; plus some working space. If that's not the case you can unpack on something else with more free space and then stop kodi and move files back to where they need to be. Doing things manually isn't so hard.

Start by pushing your changes and commits into a GitHub repo so that the changes you've made can be seen and inspected.

I was under the impression the script was explicitly executed so didn't require "chmod +x /storage/.config/autostart.sh" to be run, but that might be worth checking too.

Have you added "dtoverlay=allo-digione" to config.txt ?

Some BT devices require you to "pair" them, and some require you to "trust and connect" the device.

I've removed the HOWTO tag because that approach to installing (and all internal emmc installs) should be discouraged. We already see too many issues with people who don't know what they're doing running scripts and shell commands against Android boxes.

Boot the U9 with Android. If it's still 'dark' it's simply the differences between different hardware. If it's great in Android then you probably have a solution because nobody is really working on the 3.14 kernel that S912 devices are stuck with for now.

Just a hunch .. disable MMAL decoding and use OMXplayer instead.

echo "(sleep 10 && /storage/urserver-3.6.0.745/urserver --daemon)&" > /storage/.config/autostart.sh

^ that should work as long as the /full/path/to/urserver is valid. It waits 10 seconds and then executes the command in the background. If you don't background the task the process will be correctly killed on script exit.

DNS caching is disabled by default because it results in the Kodi GUI showing 127.0.0.1 as the DNS server and 9/10 n00b users trying to solve any networking problem wrongly point the finger and report "DNS is broken" as the bug. If we disable it, Kodi reports whatever the DHCP server sets as your DNS servers and all the bug reports stop. The secondary reason is that we found it to be occasionally problematic, and the genuine bug reports also stopped once it was disabled.