Posts by mglae

There is no complain about video in the thread so I expect it to be working.

This thread shows finally a successful installation of 11.0.0 on an Intel Atom Z3735F.

For a test create an installation stick of Generic or Generic-Legacy and boot into run mode. The installation will not be touched.

Usually a Z3735F Bay Trail is using a 32bit EFI BIOS. You have to edit grub.cfg in this case.

Quote from ajbathe

Any idea how we can debug that more deeply?

First enable Persistent Logging in LibreELEC Setting Addon's service tab to avoid journal wrap.

To enable connman's debug logging for iwd and wpa_supplicant create with path:

[Service]
Environment=CONNMAN_DEBUG=--debug=../plugins/iwd.c
Environment=CONNMAN_SUPPLICANT_DEBUG=1

And reboot.

Use only --debug to enable all connman debug messages. There are other environment variables that can be set.

You may find it convenient to attach a keyboard and use the tools.gbmshell addon for network configuration.

A likely good post to start is RE: Xandr Replacement.

You may have to change the name for your HW.

To create the modprobe configuration file:

echo 'option iwlwifi amsdu_size=3' > /storage/.config/modprobe.d/iwlwifi.conf

Then reboot.

There are iwlwifi errors/crashes:

Mar 07 16:34:28.694546 LibreELEC kernel: iwlwifi 0000:00:14.3: Queue 10 is active on fifo 1 and stuck for 10000 ms. SW [208, 224] HW [208, 224] FH TRB=0x0c010a0df
Mar 07 16:34:28.696267 LibreELEC kernel: iwlwifi 0000:00:14.3: Microcode SW error detected. Restarting 0x0.
Mar 07 16:34:28.697666 LibreELEC kernel: iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[...]
Mar 07 16:34:28.728650 LibreELEC kernel: ieee80211 phy0: Hardware restart was requested

A web search leads to https://bugs.gentoo.org/show_bug.cgi?id=721064. You can try the tips in the last post.

netbooker Looks like the EFI BIOS is requiring an explicit boot entry. The LE installation assumes the BIOS is booting the /EFI/BOOT/bootx64.efi by default.

Please follow RE: LibreELEC doesn't start after the first installation to create the entry.

chewitt The installer is always creating a 512MB FAT16 partition.

synologynas is likely a local hostname to be resolved.

Unfortunately resolving host names via nmblookup was dropped from kodi 20, now DNS lookups are finally used.

You can try to enable WS-Discovery via Settings->Services->SMB Client.

To avoid reinventing the wheel a link to the excellent Audio Quickstart Guide in Kodi Wiki should be enough.

Quote from titoasi

Do logs persist after reboot? Or they start loggin on each boot? Because then I don't see anything that caused the crash

There is almost never a reboot, only kodi is crashing. In this case you do see it in

Feb 24 16:10:19.617112 TitoasiRB kodi.sh[860]: Segmentation fault (core dumped)
Feb 24 16:10:34.647132 TitoasiRB kodi.sh[860]: Crash report available at /storage/.kodi/temp/kodi_crashlog_20230224161019.log
Feb 24 16:10:34.685475 TitoasiRB systemd[1]: kodi.service: Main process exited, code=exited, status=139/n/a
Feb 24 16:10:34.720498 TitoasiRB systemd[1]: kodi.service: Failed with result 'exit-code'.
Feb 24 16:10:34.720994 TitoasiRB systemd[1]: kodi.service: Consumed 20min 44.716s CPU time.
Feb 24 16:10:36.842051 TitoasiRB systemd[1]: kodi.service: Scheduled restart job, restart counter is at 1.
Feb 24 16:10:36.842767 TitoasiRB systemd[1]: Stopped kodi.service.
Feb 24 16:10:36.842817 TitoasiRB systemd[1]: kodi.service: Consumed 20min 44.716s CPU time.
Feb 24 16:10:36.863162 TitoasiRB systemd[1]: Starting kodi.service...
Feb 24 16:10:36.875145 TitoasiRB systemd[1]: Started kodi.service.

Pasting the Crash Logs via LE Settings Addon will give more information.

Maybe someone know what the burst of kodi.sh[864]: Failed to import fence to syncobj: -1 means.

With ssh you can use kodi-remote on the device.

It is ever possible to connect a (maybe cordless) keyboard.

AutoConnect is OK.

You can provide the usual pastekodi system log. Maybe someone gets an idia.

Quote from Glorious1

I'm still wondering why that change was needed for me when it wasn't for others.

You did not mention before you are using a case with fan and likely did install some software intercepting the power off path.

Quote from Glorious1

Only thing is, the case fan stays on, which I guess is expected because apparently the power to GPIO pins remains on as long as there is power connected to the Pi.

That is to be expected. The halt target only stops the CPU and nothing from the chip set.

You can use halt target instead of poweroff target:

ln -s /usr/lib/systemd/system/halt.target /storage/.config/system.d/poweroff.target
systemctl daemon-reload

There have been issues with the autoconnect status in the past, please check with:

grep AutoConnect /storage/.cache/connman/*/settings

"Still something missing to completely support your card."

I've no idea if there is currently an out of kernel tree driver required.

Do you use the recommended BIOS settings?