Posts by chewitt

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

    rawnar You create an SD card using the "box" image then boot from SD card and download or copy the "wetek-hub" board image over to /storage, then write the board image to the internal eMMC storage using emmctool, power off, and then boot. If the issue is fixed, the device boots fine. If it is not fixed, boot will not complete as noise on the UART lines is seen as a keypress and forces you into the u-boot console instead of booting into Linux. To recover from that you will need the 3.5mm to DB9 serial UART adapter WeTek originally shipped with the box, and some kind of DB9 to USB serial UART adapter (as computers don't have DB9 serial ports these days).

  • [x86-64] Video playback goes through PC speakers

    Yes, that would explain everything. You captured from a monitor with no audio capabilities and that's what the device still sees as connected. So, self-inflicted problem. In future please share logs with "pastekodi" so we can see the system log in addition to the the Kodi log (and without having to download from the forum) .. would have saved a load of time as we'd be able to see the EDID forcing in kernel boot params and other info.

  • [RPi4] No HDMI audio on LibreELEC 10, 11 and 12

    Code
    EDID of '/sys/devices/platform/gpu/drm/card0/card0-HDMI-A-1/edid' was empty.

    That's from the LE 12.2 system ^ and it explains why there are no HDMI audio devices listed in Kodi. The system log shows that the kernel detects HDMI audio card hardware on the RPi4, but as the connected HDMI device advertises no audio or video capabilities, Kodi is filtering that device out from the list. The AVR probably doesn't advertise capabilities as the projector is connected via DVI and DVI is a video-only connection type.

    The LE9.2 log shows that HDMI output is forced on using config.txt (which we suspected). I'm unsure what the exact mechanism used in the older display pipeline was, but this results in the kernel (and thus Kodi) seeing basic video and audio capabilities.

    That config.txt approach no longer exists in the current (no longer new) display pipeline. You can force the initial resolution and bit-depth for a DRM connector using kernel boot params but audio works entirely from the EDID data presented over HDMI. You can trick the kernel into seeing an HDMI device as always connected, see https://wiki.libreelec.tv/configuration/edid but this still requires an HDMI device with EDID data showing audio capabilities to capture from.

    Suggestions:

    a) Configure the AVR to mirror the video output on multiple connections, i.e. an HDMI output being available might result in audio capabilities being advertised with output mirrored to the DVI output.

    b) Configure the AVR to not pass-through the upstream device capabilities resulting in the RPi4 seeing an AVR with audio capabilities instead of a (DVI) video device with none.

    b) Capture EDID data from an HDMI device that does advertise audio capabilities. This will force the kernel (and Kodi) so see that device as connected. However this will dictate video output capabilities in addition to audio, so you might encounter display issues from the kernel attempting to use display modes that don't exist on or align with the projector.

    c) External HDMI to S/PDIF audio-splitter devices normally inject audio capabilities to the EDID on the HDMI connection so that audio can be sent to it (and then split out) with the video portion of HDMI connection passed through to the next-in-chain device.

    Beyond that I'm out of ideas /shrug

  • [x86-64] Video playback goes through PC speakers

    In the first playback attempt in the file (H264, 5.1 EAC3 audio) alsa first attempts to open the HDMI device:

    However this advertises no audio channel map data, see the ^ "UNKNOWN" so the alsa sink looks for a better output:

    The sysdefault entry (mapped to the analogue output) advertises FL/FR so this is selected and used.

    This is probably an issue with EDID/ELD data missing on the HDMI connection. I note that the only display-info in the log is:

    Code
    2026-02-25 22:50:24.109 T:2694     info <general>: [display-info] make: 'LG Electronics' model: 'LG FULL HD'

    Kodi also detects a limited set of resolutions (to me this looks like a monitor not a TV):

    but in a normal system, I'd expect something like this:

    and a set of resolutions like this:

    I haven't looked at source code, but I suspect Kodi blindly uses whatever audio device has been configured when outputting audio for GUI sounds; while media playback has logic to consider speaker layout so you get a different result.

    The normal cause of missing EDID/ELD data on HDMI connections is either cables or adapters (not passing it along). So you might have a cheap DP to HDMI adapter designed for presentations (supports video but not audio) or the DP chip in the Lenovo is doing something odd, or the HDMI cable might be bad, or perhaps there's something in BIOS/firmware settings, or perhaps the TV (or is it a monitor) outputs EDID that simply doesn't advertise audio /shrug

    The possible workaround is https://wiki.libreelec.tv/configuration/edid#intel done from another Linux device (that does see audio capabilities) and then transfer that configuration to the Lenovo. This will result in the kernel (and thus Kodi) seeing a TV with some audio capabilities as connected, and it will then try to transmit audio on the HDMI connection instead.

    In short, I don't see Kodi doing anything wrong here, and it looks like a local hardware problem.

  • Enable AEC default for mic (RK3588)

    a) It appears you already wallpapered the internet with the same request (based on 10 seconds of Google search).

    b) There is no current use-case for microphone input on LE (so your request has nothing to do with LE).

    c) There are no "developers for hire" in this forum.

    Marking the thread closed as you're clearly just spamming every forum that has any connection to Rockchip hardware.

  • [RPi2B] Invalid Key/WiFi issues with USB dongle

    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.

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    Quote from DeViLRuNNeR-dev

    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.

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    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.

  • Kodi not seeing NVME SSD recognized in Raspberry Pi OS and formatted as EXT4

    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?

  • Problems during loading of TVHeadEnd

    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.