Posts by chewitt

    The splash screen is broken. It shows the same “damage” on every boot, and it's been like that since at least LE11

    That's the Kodi Omega (21) splash screen. The glitches are intentional and part of the splash. Kodi Piers (22) moves back to a more normal one.

    If you are using "adjust refresh" in Kodi config so it switches mode to match the media being played can you disable that and force all media to 1080@60. If you are not using that, please enable that and define 1080@60/59.94/50/24/23.976 modes and allow mode doubling. Do the changes make any improvement?

    Over time we received more abuse from people demanding we require stronger passwords than people demaning the ability to set weaker passwords. So the current status quo is intentional and we have no plan to change that. Just skip ahead to the point where you've installed an SSH key and disabled passwords and the entire issue is moot.

    You can disable wifi via device-tree overlay in config.txt to eliminate that although it's unlikely to be an issue unless the PSU is not sufficient. You can also add "textmode" to boot params in cmdline.txt and the OS will boot to a text console instead of Kodi so you can either connect a USB keyboard or SSH in to delete/move the open-meteo addon from /storage/.kodi/addons and look at Kodi crashlogs for clues. Revert the change and reboot and it will boot back into Kodi again.

    Software downscaling 8K media to 4K sounds like a bad idea. If you want to use 8K media get an 8K capable TV and play content at the native 8K mode of the panel. Configure Kodi along the lines of https://wiki.libreelec.tv/configuration/4k-hdr and allow the TV to upscale 4K and 1080p modes to the 8K native panel resolution. The article doesn't mention 8K at all but the same issues and basic principles apply.

    As a general rule Intel seem to be more active in maintaining drivers and nVidia is on the long-term 'avoid' list as drivers still require X11 (so no HDR) but I haven't personally used Intel/AMD/nVidia hardware for more than a decade now so I can't really comment on the current state of anything.

    I would personally guess the issue is more likely to be in the kernel DRM layer than mesa, and more likely to be incomplete drivers than a bug in something. There's no factual basis for the comment though, I'm just guessing.

    You can clone the embedded Estuary skin folder to /storage/.kodi/addons then modify addon.xml to change the name so it doesn't clash with the embedded version, then mod as you like.

    You're also welcome to experiment with webmin via docker, but LE is not a derivative of any other distro and our layout is rather non-standard which normally trips up tools that expect conventional Debian/Fedora packaging.

    You can't for two reasons:

    a) There is no package manager to install packages like webmin

    b) The userspace filesystem is decompressed from SYSTEM on each boot, and is read-only

    It's possible to install the Docker add-on and the pull a webmin container, but webmin is going to assume a standard Linux distro with a normal filesystem layout where everything is read-write, so you'll find most (all?) features are non-functional.

    Why do you think you need webmin?

    I dug out one of my boxes. It was already installed with a working LE 11.0 install, but I updated using the latest LE13 image in my test share and the update overwrites/replaces all the boot files, and it rebooted fine afterwards.

    The boxes I have are still running the original pre-production boot firmware as I'm not an O2 customer (or in CZ) so the boxes have never been been updated. Yours probably has been, and may also be a newer hardware iteration; although I believe the only change made over time was a different WiFi/BT module, that won't prevent boot, and if Armbian boots the box can boot LE.

    You probably need to do a 'toothpick' reset to ensure u-boot searches/finds and loads LE boot scripts from the SD card. These define what boot files to use, and LE uses different files to Armbian.

    Boot Log: https://paste.libreelec.tv/great-stallion.log

    The refresh rate is not clear in the PVR stream so Kodi needs to start playback to detect it and then switch to the correct rate.

    I would try configuring the resolution whitelist like this https://wiki.libreelec.tv/configuration/4k-hdr

    I would also define the PVR fallback refresh rate to 59.94Hz as this appears to be what the streams are using. Right now Kodi tries to play at 25Hz and then switches. I'm wondering if this setting defines the initial rate that Kodi attempts? (not guaranteed, I'm not familiar with the setting or how it works in code). If not, setting the desktop refresh rate to 59.94 (not 60.00) might work better.

    Have a play and experiment.

    Code
    # SPDX-License-Identifier: GPL-2.0-or-later
    # Copyright (C) 2009-2014 Stephan Raue ([email protected])
    # Copyright (C) 2019-present Team LibreELEC (https://libreelec.tv)
    
    ACTION!="add|change", GOTO="end"
    
    DRIVER=="ehci-pci|xhci_hcd", RUN+="/usr/bin/sh -c 'echo disabled > /sys$devpath/power/wakeup'"
    
    LABEL="end"

    Create that ^ as /storage/.config/udev.rules.d/30-disable-wakeup.rules but ensure you do this via SSH/nano to ensure unix line endings are used (as Windows endings will not work). You can stop/disable and then delete the systemd service file.

    Working?

    Create the custom systemd service as /storage/.config/system.d/xhci.service

    Enable with systemctl enable /storage/.config/system.d/xhci.service

    Start with systemctl start /storage/.config/system.d/xhci.service

    Then check for errors. If you need to make changes and edit the file, run systemctl daemon-reload after the changes.

    Aside from the odd /storage location, systemd things work the same as most other distros.