Posts by kurai

    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:

    Code
    - 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

    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.

    Bash: boot_to_windows.sh
    #!/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.

    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. :thumbup:

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

    Code
    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 ...

    Code
    #PrintLastLog yes

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

    Code
    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 :blush:

    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)

    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 :P

    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 ?

    Yes - the problem seems to be that at boot time the ExecStart=/usr/lib/samba/samba-config initiated from samba-config.service failes to create (or create in time ??) the /run/samba/smbpasswd that smbd is looking for during startsmbfilepwent_internal , so smbd recreates an empty smbpasswd file.

    Executing /usr/lib/samba/samba-config later in an SSH session *does* create a proper /run/samba/smbpasswd

    So, my question is ... how do I ensure that a populated smbpasswd file is created and|or created in time for smbd to find ?