Posts by chewitt

    GamerBene19 it would be good to see connman debug + iwd debug logs during an invalid-key failure, and then the equivalent connman debug + wpa_supplicant debug during a successful connect, with both running on an LE13 master branch base. The goal would be to throw the logs into something like Claude AI with a prompt telling it to trace the interactions and find the root cause of the invalid-key failure. It may come up with a load of garbage. It might come up with something insightful. I've had some success with it tracing complex sequences of activities accross multiple binaries to find bugs in media codecs so you never know.

    Commit d39e2d1 kinda describes what I am seeing in mainline/upstream kernels. How would one ask for these to be included in current-rockchip64 kernel builds?

    The same change is present in the rockchip-6.19.y branch: https://github.com/chewitt/linux/…9847573205c326a used in my test images and the same will be in LE13 nightlies. If you want to have the same fix in some Armbian release (we have no rockchip64 kernel builds) go ask their devs to copy the patch from my tree.

    f1gogata If you have been running Oleg's older RK images I have no understanding of how the board is booting or what u-boot versions are installed, but you probably need to a) erase the vendor u-boot that Khadas oocrap installed to SPI flash, as this has boot priority over the emmc device, and b) ensure an LE image has been written to emmc using dd to ensure u-boot 2026.01 is present on emmc to boot the device once SPI flash has been erased.

    To erase SPI flash, run dd if=/dev/zero of=/dev/mtdblock0 bs=1M from any Linux OS that boots.

    To write LE to emmc, boot an LE image from SD card or USB stick (so emmc is not in-use) then transfter a current LE13 image over to the /storage partition and use emmctool to write the image to emmc.

    The fuzzy screenshot shows a system booted from SD card with swap devices so this is presumably from RPiOS and not from an LE install. The same image shows the NVME device has no mountpoint so while the physical hardware is visible, it probably hasn't been partitioned and formatted for use, and for the same reason it will be physically visible but unusable in LE too.

    The simple fix is to partition and format the device, but are you wanting to boot/run from the NVME device or continue booting from an SD card with the NMVE drive used only for persistent /storage?

    I'm reading the thread and the main developer (Florian) is asking for a specific issue to be separated and debug logs to be provided to aid triage/investigation; and while a few insults and accusations are then made, nobody opens the issue and nobody provides the debug logs; the issue is not investigated, and after some time with nobody doing as asked the ticket is closed. And all you're saying here is #metoo which doesn't achieve anything. Florian is generally helpful but also a typical software engineer with a process and methodology for investigating things. If the people impacted by a problem can't be bothered to follow the basic process he's asked for, there are many other things that need his attention and he'll keep himself busy working on those instead.

    Forward motion is generated by people doing things, not talking about them. If you want your problem to be fixed, feel free to open a ticket and engage.

    I've pushed updated RK3588/RK3576 images that appear to have HBR formats "working" to some level now, although I hear some glitches on a few files that could be underruns or some kind of DP/HDMI bandwidth issue.

    I don't see channel mapping issues with speaker-test -D hw:hdmi0,DEV=0 -c 6 on a Rock 5B board. Channel mapping was an issue in the past, but Kwiboo spotted the problem some weeks ago and a fix was submitted upstream.

    If you see issues with SMB shares perhaps experiment with different SMB chunk size values in the Kodi SMB client settings. I see no issues with 50GB+ sized ISO rips (other than start being slower) so that sounds more like an environment or media problem.

    This describes our generally recommended configuration: https://wiki.libreelec.tv/configuration/4k-hdr .. using adjust-refresh with the mode whitelist gives the best experience. There is no need to set anything in advancedsettings.xml.

    There is one outstanding audio bug https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10199 for which there is a workaround hack available while we continue to pester Intel devs about a fix: https://github.com/LibreELEC/LibreELEC.tv/pull/8588.

    LE uses u-boot 2026.01 but with the vendor rkbin used in the boot recipe rather than TF-A which still seems to be maturing; I leave boot things to Kwiboo to guide on since that's more his thing. You should be able to achieve the same under Armbian with the same kernel/ffmpeg/kodi versions and patches and the same alsa configuration, although if using Kodi under Wayland you will be stuck with everything running at the desktop resolution/refresh rate as Wayland does not support the dynamic switch that LE uses when running Kodi GBM. NB: there are way too many patches required right now, but over the next couple of kernel cycles a large number of things should have been merged and the delta between the bleeding-edge and upstream will reduce.

    I don't see anything abnormal logged; using an AMLGX image on an N2 board, with the timezone configured for Asia/Dubai or with the timezone changed to Europe/Warsaw:

    Code
    N2:~ # connmanctl clock
      Time = 1771724187
      TimeUpdates = auto
      Timezone = Asia/Dubai
      TimezoneUpdates = auto
      Timeservers = [  ]
      TimeserverSynced = True
    Code
    N2:~ # grep -i bias /storage/.kodi/temp/kodi.log
    2026-02-22 05:35:27.952 T:808      info <general>: Time zone bias changed from 0 mins to -240 mins (due to time zone or DST change).

    If there was a general issue with timezone configuration and ntp updates (ConnMan) there'd be a ton of forum posts on the topic; and there are a decent number of people using LE13/K22 nightlies and this is the only report. This normally points towards an issue being network/environmental related and not something in the LE image.

    Have you tried rebooting your internet router?

    I've never heard of people playing games on DVD discs until recently but apparently this is a real thing. I'd guess you need the JRE-Zulu add-on from the LE repo so that Java things on DVD media are possible in the first place. Then open some discs and see what happens. This is firmly at the niche end of things so no guarantees.