Posts by chewitt

  • S905D sml5442tw - Won't Boot

    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

  • LiveTv channel change delay display a black Screen

    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.

  • [x86-64] Random Crashing

    If you read the code you'll find that in lots of scenarios Kodi tests for capabilities and makes code-path decisions based on whether something succeeds (is supported) or fails (is not supported). Both 'errors' are normal and harmless.

  • [x86-64] Setup for XHCI Suspend/Wakeup

    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?

  • [x86-64] Setup for XHCI Suspend/Wakeup

    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.

  • New ASUS NUC 14 Essentials doesn't see wired Ethernet NIC

    You will be able to update to the main LE13 release when it comes, although (as with the original poster) if the board needs Linux 6.14 to support the NIC and the release image is using Linux 6.12 (the current plan) that will cause problems. I'm going to start an internal discussion about moving the Generic image to a newer kernel, but it's a group decision, so not guaranteed.

  • New ASUS NUC 14 Essentials doesn't see wired Ethernet NIC

    Quote from goAtsy

    Are some more likely to be stable than others, due to some development cycle or similar, or is it random?

    The devil is in the details of what specifically changed on a day-to-day basis. We tend to queue anything majorly distruptive for the start of the release cycle but in recent years even those have been quite smooth. For context, the family daily-driver RPi5 has been running dangerously unstable sounding "pre-alpha" K22 images for more than a year now without any drama. Hopefully K22 will start lurching towards release soon.

  • [RPi4] Crashing Repeatedly During Movie

    XML
    <?xml version="1.0" encoding="utf-8" ?>
<advancedsettings version="1.0">
  <loglevel hide="false">1</loglevel>
</advancedsettings>

    That ^ content will enable debug logging without the OSD.

    The current log is /storage/.kodi/temp/kodi.log and previous log is kodi.old.log, there are kodi crashlog(s) in the same folder. The current and previous log are rotated with each reboot so they are persistent but not preserved. Crashlogs are preserved.

  • Official LE13 Test Images for Amlogic (Kodi-22)

    Code
    Apr 03 22:34:29.889183 LibreELEC kernel: ALSA device list:
Apr 03 22:34:29.889203 LibreELEC kernel:   No soundcards found.

    The kernel doesn't detect/setup the audio card; hence nothing is seen in Kodi.

    The OF: /sound: Read of boolean property entries in the system log are unusual and something I'll look into, but I don't think they are related to the issue as I also see them on an Odroid N2 board here which has the audio card detected fine.

    I don't have any Dreambox hardware so I'll need to defer investigation to _emanuel_ who does.

    EDIT .. this is more concerning:

    Code
    Apr 14 18:27:14.278630 LibreELEC kernel: platform ff642240.audio-controller: deferred probe pending: platform: supplier ff642280.reset-controller not ready
Apr 14 18:27:14.279563 LibreELEC kernel: platform audio-controller-1: deferred probe pending: axg-tdm-iface: failed to get sclk
Apr 14 18:27:14.280314 LibreELEC kernel: platform ff642540.audio-controller: deferred probe pending: axg-tdmout: failed to get pclk
Apr 14 18:27:14.281349 LibreELEC kernel: platform sound: deferred probe pending: axg-sound-card: can't parse dai
Apr 14 18:27:14.282533 LibreELEC kernel: platform ff642480.audio-controller: deferred probe pending: axg-spdifout: failed to get pclk
Apr 14 18:27:14.283568 LibreELEC kernel: platform ff642680.audio-controller: deferred probe pending: axg-spdifout: failed to get pclk
Apr 14 18:27:14.284233 LibreELEC kernel: platform ff642744.audio-controller: deferred probe pending: (reason unknown)
Apr 14 18:27:14.284768 LibreELEC kernel: platform ff642280.reset-controller: deferred probe pending: meson-audio-arb-reset: failed to get clock
Apr 14 18:27:14.285620 LibreELEC kernel: platform ff6421c0.audio-controller: deferred probe pending: platform: supplier ff642280.reset-controller not ready
Apr 14 18:27:14.286495 LibreELEC kernel: platform ff642200.audio-controller: deferred probe pending: platform: supplier ff642280.reset-controller not ready

    Possibly something wrong in device-tree then.

    The current nightly images are Linux 6.14.2 the same as my images. If you go back a month to an LE13 nightly image that uses the older 6.12.y kernel is anything different? - share the system log, ideally with 'debugging' removed so the log is not full of verbose connman content.

  • RFC: Project BootELEC

    Maintaining our apex position is about keeping the power to shepherd limited resources and control our workload, not to dominate others, there's no agenda for that. The same cannot be said for some of the downstream elements of our ecosystem.

    I'm home again from Tuesday so if you're around in evening hours (GMT+4) ping IRC and we can chat.