autostart.sh is depending on network-online.target but you have to adjust Wait for network before starting Kodi in LE-Settins addon from the initial short 10 seconds to your needs.
Log messages of autostart.sh can be viewed with journalctl -u kodi-autostart. The status of "Wait for network" is visible with systemctl status kodi-waitonnetwork
Addons are updated independent from releases. Expect it any time after PR commit.
I've created a LE12 fix for this.
Note: you have to revert any script.xbmc.boblight changes after the update is installed.
Err, this does not match your test procedure. Better modify the source if debug is needed.
I use the "run" option. Every image build is written freshly to the USB stick. I don't use SFTP/update
Then you also start every build with a fresh BT configuration, the test should be good.
A log comparison between working and not working state may result in additional information.
bluetoothd can be forced to debug mode with (but I don't know how noisy it is):
[Service]
Environment=BLUEZ_DEBUG=--debugUsually re-pairing is not required. Latest connection is stored in the keyboard and in LE below /storage/.config/bluetooth/. Do you boot "live" or "run"?
And what about adding the --enable-hid2hci option
Was not included inLE10 and LE11, so likely not required. But just do the simple test and the question is finally answered.
You do need reliable test procedures for a successful bisect process. Here the test is to connect the keyboard to the test system, nothing is required on the build system.
If the keyboard is detected you do have a "good" case, no questions. But without detection: is this caused by the code error ("bad") or only a temporary fault?
From your experience with working code (even in LE11, LE10 ...): how reliable is the keyboard detected?
Maybe you need more boot tries if you see "bad". This is only a suggestion. Your experience is required to optimize the bisect test procedure.
gobex: const annotate RO arrays, use G_N_ELEMENTS: I'm having some doubts that a change to an obex lib is causing your keyboard error.
There may be false negatives (e.g. detection of the BT keyboard is delayed) interrupting the bisect process.
With using the USB stick you can even avoid the reboot when updating by replacing both KERNEL and SYSTEM with the new generated *.kernel and *.system files.
Add . /etc/profile to include System Tools Addon path.
Change download source:
diff --git a/packages/devel/commons-text/package.mk b/packages/devel/commons-text/package.mk
index c0277ca900..654ba2112a 100644
--- a/packages/devel/commons-text/package.mk
+++ b/packages/devel/commons-text/package.mk
@@ -6,7 +6,7 @@ PKG_VERSION="1.11.0"
PKG_SHA256="4169cb90571fb28fad4c5eea7c1c994c18f1995452f73e8ea7a86087c0e3822e"
PKG_LICENSE="Apache-2.0"
PKG_SITE="https://commons.apache.org/proper/commons-text/"
-PKG_URL="https://dlcdn.apache.org/commons/text/binaries/commons-text-${PKG_VERSION}-bin.tar.gz"
+PKG_URL="https://archive.apache.org/dist/commons/text/binaries/commons-text-${PKG_VERSION}-bin.tar.gz"
PKG_DEPENDS_TARGET="toolchain"
PKG_LONGDESC="Apache Commons Text is a library focused on algorithms working on strings"
PKG_TOOLCHAIN="manual"Development is always done on master. But don't use branch name master yourself.
Create your own working branch with e.g. checkout -b my_first_working_brach master. If you like to test something else, commit you local changes and create a new branch.
master is only used to follow the official GitHub branch. With special requirements it is of course possible to create your working branch from an older commit.
There is no difference in installer, boot loader and kernel between Generic and Generic-Legacy.
With using 512 byte sector size the syslinux legacy boot loader was now successfully installed and can be used for Legacy Boot.
Regarding UEFI boot: likely your system firmware require an explicit entry for the default EFI loader at "\EFI\BOOT\bootx64.efi". LE rely on having the loader executed by default. See this howto for creating the entry. It may be easier to use a live linux system with efibootmgr.
Better use -L "LibreELEC" on your system, "Windows Boot Manager" may already be used and is required only on the M72e as work around.
IIRR permission modifications are possible when using SMB1 with Samba Unix Extensions. SMB1 is deprecated for good reasons today, please don't use it.
Changing permissions on /storage can be critical for system files and directories below /storage/{.cache,.config}. But because being "hidden" directories they fortunately may not be affected by your modification.
Unfortunately the changes do include kernel (6.6.19 to 6.6.21) and bluez (5.72 to 5.73) updates.
Did something change in the Bluez package?
If motivated you can try related older nightly from USB stick with run option.