Posts by mglae

Use the included tool systemd-escape yourself to create the correct file name, see post #5.

This can even be reversed (name to path of the wrong unit name):

# systemd-escape --unescape -p storage-storage-win
/storage/storage/win

verified-herring.log contains:

/storage/.config/system.d:
-rw-r--r--    1 root     root           408 May 17 23:09 pulseaudio.service

harmless-marlin.log contains:

/storage/.config/system.d:
-rw-r--r--    1 root     root           425 May 18 09:21 pulseaudio.service

?

# systemd-analyze verify storage-win.mount
storage-win.mount: Where= setting doesn't match unit name. Refusing.
Unit storage-win.mount has a bad unit file setting.

Create the correct name:

# systemd-escape -p --suffix=mount /storage/storage-win
storage-storage\x2dwin.mount

Quote from Abacus

have commented out this line:

[...]

So there is no log without your changes?

If you are still interested in using chrome and/or tigervnc you may "update" to Generic-legacy image (only require to erase /storage/.kodi/addons/packages and manual reinstall a few binary addons). This will drop HDR support (if the chip set has the capability)

Quote from Abacus

because I don't know exactly where to deactivate PulseAudio permanently.

systemctl mask pulseaudio,service

LE is configured to run with both ALSA+pulseaudio. What did you changed in the pulseaudio.service copy before?

PS: remove or disable tigervnc. It is only working with X11 of Generic-legacy

1. It's no debug log, please reboot with kodi debug log enabled. Edit: Sorry, was already a debug logg.

2. If stopping pulseaudio is still required post a second debug log too.

I'm afraid the used chrome command line options are outdated.

You can start with removing--use-gl=desktop . Forcing LIBVA_DRIVER_NAME='i965' can be an issue too.

Output of systemd units are logged to journal by default and only copied to console.

See StandardOutput= entry of systemd.exec

Quote from bumrufus

i hope someone finds a solution for not updating the repos

Increase Wait for network before starting Kodi in LE-Settings addon from the initial short 10 seconds to fit your needs. The repos are initially updated at startup (and periodically later).

I recommend the max time you are willing to wait when no network is available.

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.

Quote from ehoitinga

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=--debug

Usually 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"?

Quote from ehoitinga

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.