Posts by kurai

TL;DR

Weirdness with random USB <-> SATA adapter. Booting once with disk attached somehow reset/cleared the issue and it now sleeps/resumes as expected.

Not worth anyone elses brainpower to dig deeper into root issue, so marked as solved.

Finally got around to poking at this in a more organized way.

The hardware that triggers the bug turns out to be a USB SATA adapter (JMicron JMS578 based).

No onboard SATA sockets on this SBC, just NVME, so I use this to plug in an ancient spare SATA SSD to do occasional full disk image block-based backup snapshots with Clonezilla - more frequent when I'm futzing around with LE nightlies. I usually leave the adapter plugged in and only stick the SSD on the end when I want to trigger a backup.

(Script detects SSD volume being mounted, runs efibootmgr --bootnext 3; to select the SSD at next boot instead of the default NVME device with LE on it, reboots, runs an automated Clonezilla session from the SSD, saves the backup locally to a dedicated partition on the SSD, then reboots again, once done, from the default NVME boot device, back into LE.)

Aaaaaanyway - systematically going through the various bits of installed hardware, the hang on resume-after-sleep went away after unplugging/boot/replugging/boot of the JMicron SATA adapter (without and disk attached).

Puzzling - I saw that lsusb / dmsg only listed the JMicron device when it had a disk attached. I unmounted the disk and unplugged, leaving USB adapter in place and rebooted ... and now the sleep resume test worked just fine, as it did with LE12.x stable.

Huh.

Now I can't recreate the hang condition.

Maaaaybe there's only power running through the adapter's chipset when there's a SATA device attached, completing a circuit?

Maaaaybe booting with a SATA disk attached reset/cleared some non-volatile state register in UEFI ?

Maaaaybe some change to S3 sleep parameters/implementation was buried in the depths of one of the kernel releases ?

Maaaaybe it's just ghosts ?

This seems like a bizarre edge case of circumstances and hardware unlikely to ever affect anyone else, and ultimately not worth wasting any of the LibreELEC team's time on, so I'll close this and we can all move on with our lives

On an Odroid H4 (Intel N97 Alder Lake x86 SBC) attempting resume from S3 sleep now results in a locked up state where system powers on but does not progress to restoration of OS & Kodi state.

It's a hard lock-up - doesn't respond to the reset button and requires a 4-second press on PWR to force hard power off. System does a normal cold boot at next power-on.

Has something fundamental changed in LE13 with the resume/sleep management ? (Maybe kernel version or something in the Linux scaffolding of LE's x86 build ?)

For further information, state & meaning of the 5 onboard diagnostic LEDs:

- Red (PWR) – Solid light when DC power is supplied
– Blue (left, SLEEP) – turns off only when the system enters into suspend mode
– Blue (right, PMIC) – turns on only when the major power rails are working
– Amber (SATA) – Flashes when SATA data transfers
– Green (NVMe) – Flashes when NVMe data transfers

In normal powered-down state with PSU still connected:

\ Red \ - - - - \ - - - - \ - - - - \ - - - - \

In regular powered on running state (Amber & Green flash as disk I/O happens) :

\ Red \ Blue-L \ Blue-R \ - - - - \ - - - - \

After a failed resume the system LEDs show:

\ Red \ Blue-L \ - - - - \ Amber \ - - - - \

The presence of the solid Amber LED (SATA) seems slightly anomalous - there are no SATA devices present, the only disk in the system is an M.2 NVME

In normal operation and with prior LE12 builds the Green NVME was the only I/O LED that flashes at any point.

Grasping at straws ... Perhaps something is making a faulty assumption that a SATA device should be present, and is hanging the resume process as it waits for a response that will never come ?

I am somewhat stuck at this point as I don't have a further way to diagnose the resume process - logging stops in what looks like a normal manner after S3 sleep is triggered and proceeds to shutdown state. Given that I have to hard power-off and cold boot after this point there isn't any logging available for the S3 resume sequence, just the kodi.old.log to the point of sleep shutdown.

Any pointers would be appreciated.

log-2025-11-04-19.28.03.zip

Thank you.

The python 3.13.9 version included with the LE 13/Kodi 22 "Piers" nightly builds breaks compatability with Milhouse's texturecache.py (v2.5.4) database maintenance script that's included in /flash at /usr/bin/texturecache.py

rainman74 has built an updated (v2.5.5) version that works with python 3.13+ (see Kodi forum post https://forum.kodi.tv/showthread.php…0283#pid3230283)

Milhouse's no longer updated original GIT: https://github.com/MilhouseVH/texturecache.py

rainman74's updated GIT: https://github.com/rainman74/texturecache.py

Can we get the updated version bundled, please ?

Can confirm the efibootmgr solution works fine with the Odroid x86 boards. (I've done it on H3 & H4)

I just made a few scripts to pick which boot option to use on next boot:-

e.g. boot_to_windows.sh, boot_to_linux.sh etc.

#!/bin/bash
efibootmgr --bootnext 2; reboot

Then you can either

1. Trigger the script(s) to via keymap.xml with RunScript() entries for using buttons directly from remote
2. Use the SkinShortcuts feature of the skin to set up a navigable menu to select the needed script(s)
3. Add entries to your Favourites menu
4. Use one of the many addons that provide a popup window with command entries you can customise.

... and so on.

Only major pain in the butt I really encountered was Windows' habit of assuming it's the only OS on the disk and then take full control of the drive's boot setup and re-write it whenever it updates to a new point-release, resulting in having to redo/re-apply the grub shenanigans.

Quote from mglae

openssh package.mk

Ah. I *think* I see what you are getting at, but I'm not at all a code-wrangler, so please correct me if I've misunderstood, or missed your point entirely...

If the utmp/wtmp options are explicitly not compiled in then there's simply no data for the PrintLastLog function to present ?

EDIT:

Doh - I'm blind - I completely missed the --disable-lastlog line outright.

Thanks for the quick answers.

I would like to enable the SSH PrintLastLog option, so that it displays before the standard MOTD as follows:-

Last login: Sat Mar 23 20:31:23 2024 from 192.168.1.2
##############################################
#                 LibreELEC                  #
#            https://libreelec.tv            #
##############################################

LibreELEC (community): nightly-20240311-86dba4b (Generic.x86_64)
LibreELEC:~ #

It's part of the vanilla OpenSSH sshd configuration options and is listed as a commented out flag in LibreELEC's /etc/ssh/sshd_config ...

#PrintLastLog yes

The normal LibreELEC method of supplying sshd overrides via /storage/.cache/services/sshd.conf ...

SSH_ARGS=""

e.g.

SSH_ARGS="-o 'PrintLastLog yes'"

... doesn't work. I've tried various ways to quote-encapsulate and supply yes|true|on|=yes|=true|=on type Boolean arguments to the -o options but haven't got anywhere.

Am I just mangling the syntax for a thing that *should* work, or is the LibreELEC sshd compiled without that particular bit of functionality that the regular OpenSSH one has ?

Thanks.

Quick bit of advice needed - before I dive into the rabbit hole of attempting to get a Wayland build of chrome/chromium running on LE12-Generic (NON legacy) ... are there any glaringly obvious STOP signs that more experienced code wranglers are already aware of that would make this a doomed attempt ?

Oops - looks like I raised a half-assed bug report. Sorry

The issue seems to be with Kodi core, rather than LibreELEC - I lost track of when I switched from LE 11.0 to 12.0 Nightlies.

I had a vague mental note to investigate why the feature wasn't working, but made the assumption it stopped *after* the switch to 12.0. In fact the RSS Ticker isn't working in any of the vanilla Kodi 12 alphas/betas.

[EDIT]

Issue raised at Kodi GitHub: https://github.com/xbmc/xbmc/issues/24229

A long standing issue with Nightly LE12 Generic builds, for at least 3 or 4 months, that I'm finally getting around to looking at.

No changes in the RSS Editor plugin (script.rss.editor - version=4.0.2) or in the /userdata/RssFeeds.xml list that it created.

Parsing the logs I can see that the URL is fetched, but nothing appears on-screen and after a while the session is closed without any further log entries.

debug <general>: Got rss feed: https://feeds.bbci.co.uk/news/world/rss.xml
debug <general>: CurlFile::Open - <https://feeds.bbci.co.uk/news/uk/rss.xml>
debug <general>: Got rss feed: https://feeds.bbci.co.uk/news/uk/rss.xml
...

debug <general>: CheckIdle - Closing session to https://feeds.bbci.co.uk (easy=0x7fc38c01f990, multi=0x7fc38c01eb00)

I've tried it in default skin as well as my normal !Transparency with same result, and all the feeds used are alive and working in a browser session.

Pastekodi log here: rssticker.log (545kB)

All working as expected now - many thanks.

mglae Thanks for that - I'll give 1500 a try.

The 9000MTU jumbo packet setting was just to keep consistent with my Unraid NAS box which has 9000 on it's 10GbE NIC.

To be honest that was an `"temporary experiment" from when I put some NVME cache drives in the server and wanted to see what throughput could be achieved. That was 2 years ago

It's only a home LAN, and the amount of time the network is really doing any serious transfer is vanishingly small, so I think I'll go back to a 1500MTU network throughout, and not lose any sleep about missing the theoretical 5-10% extra max throughput and the 7 minutes a month it might save me

Never mind - dug out an old USB 1GbE adapter (also Realtek, as it happens) and a network connection was achieved.

Created the log batch from the Logfiles share - attached here log-2023-12-09-15.40.59.zip (300KB)

The onboard 2.5GbE ethernet devices (eth0 & eth1) both seem to be detected and started without errors that I can see, but for some reason they don't show up in LE/Kodi.

My previously working device on the older nightly builds is eth1.

The temporary 1GbE USB adapter is eth2.

Can anyone see why eth1 isn't working ?

Hi.

Since about mid November the nightly 12.0 Generic builds have resulted in a booted & running LE/Kodi system, but no networking.

Device is an Odroid H3+ (N6005 Celeron) with onboard Realtek RTL8125B (2.5GbE) LAN ports.

The LE settings addon shows no available network devices in Connections.

I tried the "System and Kodi Backup" option in the addon to dump a backup to a removable drive to inspect on another system, but the function doesn't store any useful logs from Kodi or OS.

Given that there seems not to be any method to access a local console shell with attached keyboard in the 12.0 Generic builds I can't access any OS level logs at all to start digging into what exactly is failing.

Any suggestions ?

Was about to report this breaking Multi-Weather addon as trying to display downloaded map gave same _imaging.so error...

Good to see it's already in hand.

The GitHub pull #7891 [samba: samba-config: call smbpasswd with valid smb.conf] in the latest (20230619-a2c7d54) nightly looks like it's done the trick.

Thank you.

Nope - having 2 memory modules will help performance a *little* on low end/low power machines that have dual channel RAM capability, but Kodi will almost never use more than 2 GB of it.

mglae Thanks for the workaround suggestion.