Posts by chewitt

Disable CEC in Kodi drivers if not needed, then the toaster message doesn't show. Read the wiki section on calibration. No need to touch buffering settings. And Kodi Omega has a splash image that's designed to look glitchy. Not the greatest design idea. If AMLGX works for you, that's nice. If it doesn't,

I'd guess the SD card is a newer/faster one and doesn't get reset properly after the initial boot and thus can't be read-from. If you find an old/slow SD card without fancy fast modes it will probably work. Using the USB adaptor sidesteps such issues.

NB: AMLGX is not perfect. If you want to nit-pick on what works/doesn't, you can save fingers from typing forum reports about this/that test file because a) I know there are bugs, b) I know nobody is working to fix them. I'd like to see improvements of course, but until there are some, the reports aren't interesting. Best results come with using the mode whitelist and adjust-refresh. Using "sync playback to display" will probably cause more issues that it might solve. If it works for you, that's nice. If it doesn't,

I mostly use our USB/SD Creator app; albeit a currently-unreleased macOS version. And most of the time I'm using self-built images that are a little ahead of our master branch. Etcher/Rufus/Win32DiskImager should all work though, there is nothing special about our app or the .img file we build.

See if the image here works? https://chewitt.libreelec.tv/testing/

If you want to run things like teleconferencing apps on-screen side-by-side with Kodi you need a desktop or app environment where such apps exist, e.g. Ubuntu/Fedora or (don't laugh) Android or Windows. LE is not what you're looking for; unless it's being run in a virtual environment (with GPU mapped to the VM) to handle media-client activities under one of the dedicated NAS distros that allow such things.

As a general rule Linux already "does the right thing" by down-clocking CPU/GPU etc. when not active. There isn't really anything specific that you can configure or do to achieve more.

There is nothing to stop someone changing how the OS is packaged to add more users and run apps/services under different creds, but the OS was originally and intentionally designed to keep things super-simple and running under a single user is part of that. The UX design goal is to achieve 99% of tasks in the GUI and thus negate any need to go near the console (which is default disabled) and the fact the entire core of the OS is read-only largely prevents users from causing problems with errant commands. Users can rm -rf their Kodi config but in most cases a simple reboot will regenerate anything essential so the main risk is losing personal media; and users accessing their own media under their own share don't need sudo for that task anyway.

From a security perspective running everything is root is bad (no disputing that) but I've spent the last decade in/around DFIR work for my day-job and I have observed real attackers and red-team staff compromising LE devices and while I have seen devices being accessed (via known passwords) the attacker has ultimately lost interest in the device because either our distro packaging defeats scripts and other attack tooling and/or because attacker Linux knowledge/assumptions are based on the RHEL/Ubuntu derived world and/or because they couldn't ascertain what the device was for and were cautious as a result. Attackers were never able to compromise devices with basic controls deployed; i.e. SSH/SMB disabled and the firewall enabled. I'd also argue that if you are a genuine target of interest to a real actor, the "runs everything as root" LE box in your home network is the least of your worries.

There are known issues with some of the RK devices and resolutions at the moment (there are some threads in the RK section of the forum). I'm not actively following but I believe they are being looked into.

Quote from wedok

LibreELEC-AMLGX.aarch64-12.0.0-wetek-play2.img inside a Minix Neo U1.Set extlinux.conf to: "meson-gxbb-p201.dtb"

No run. Why?

This image is design to boot WP2 boxes from emmc (or SD with emmc erased). It will not boot anything else (as you discovered).

Quote from wedok

One last try ... This time with LibreELEC-AMLGX.aarch64-11.95.1-box.img @ meson-gxbb-p201.dtb

This is the correct image to use with devices with vendor u-boot. The initial boot is successful and then when the device reboots after resizing this sometimes happens; and I have no idea why. All you can do is repeat the install process until it works. You might need to check and repair (fsck) the filesystems on the SD card.

The current LE12 beta should work the same too (as it uses the same kernel).

I've boot tested SD and eMMC installs on a C2 board recently without any issues so

If the 11.0.6 image boots, I'd suggest to use that then update to the current beta (no major changes, but hey.. latest)

If there are still problems I need to see UART boot logs to see where the issue is occurring.

Something from 2018 probably runs fine still (and better than an RPi3B+) so I'd update the Chromebox firmware to current using https://mrchromebox.tech/ and make a clean reinstall with the current LE12 beta to ensure a clean state. If the current version is LE9 we don't support direct update to later releases anyway due to the Python2 > Python3 change that takes place since LE10; the core OS updates fine but add-ons can cause issues that aren't always simple for users to figure out.

echo "sleep 10" > /storage/.config/autostart.sh
reboot

I'm wondering if the issue is related to timing/scheduling during boot. That ^ should force userspace boot to pause itself for 10 secs to allow more time for the kernel to finish loading drivers and settle itself etc. before connection manager and other network setup things run. Does that make any difference? .. share a log afterwards.

Narrowing the LE changes between the two dates (as you did) flags a list of changed packages and (as mglae already commented) the two probable causes are a kernel bump and bluez bump; and of the two both mglae and myself would make an educated guess that bluez is the priority to investigate.

What needs to happen next is "bisecting" the commits/changes between bluez 5.73 (non-working) and previous 5.72 (working) to find the specific commit (or series) that introduces the breaking change. This can then be flagged/reported to upstream maintainers to get a fix, or perhaps someone can see the issue and what's needed and then we can upstream a patch.

Have you ever self-built an LE image? i.e. if you have/can we can coach on how to bisect the changes. If we have to make images for you to test and report back which worked/didn't work it's the same process .. but it'll be a lot slower.

Update to an LE12 nightly or 11.95.1 and run "dmesg | paste" after boot and share the URL so we can see the log. LE12 is still built with "CONFIG_RTL8723BE=m" enabled in the kernel but the image might be missing firmware necessary for the card to work. If yes, that normally shows in the log.

Kodi rounds values in GUI/logs and often reports 23.98 when the actual rate is 23.976. So if you're seeing 23.98 all is fine. If you're truly seeing 23.95 then something is wrong.

If you update to an LE12 image (11.95.1 or a current nightly) with Linux 6.6 kernel it will work as I described. The Linux 6.1 kernel in LE11 images is older and doesn't support the card. LE12 images will work better on an RPi5 anyways.

You need to share the URLs generated by "paste" .. we're not clairvoyant.

** LOGS NEED TO DEMONSTRATE THE WRONG SCAN **