Posts by chewitt

  • Using local hard drives

    LE will auto-mount a USB drive under /var/media/<disklabel> if the disk has a lable, or /var/media/<UUID> if not. If you plan to copy files over the network via SMB or SFTP we would strongly recommend using a Linux native filesystem like EXT4.

    You cannot format an EXT4 drive from Windows because it doesn't understand Linux partitions, but the Linux commands to run from the SSH console are not complicated. Assuming the USB drive is /dev/sdb and USBDRIVE is the label to set:

    Code
    parted -s /dev/sdb mklabel gpt
parted -s /dev/sdb -a min unit s mkpart USBDRIVE ext4 34 100%
mkfs.ext4 /dev/sdb1
e2label /dev/sdb1 USBDRIVE

    This will nuke the existing contents of /dev/sdb so you need to check the drive is /dev/sdb first. If the PC has one internal SATA drive with LE installed this will normally mount first and be /dev/sda, so /dev/sdb is an educated guess.

    If you need the option to connect and add files directly from Windows then it must be formatted as exFAT or NTFS; both of which have occasional challenges as Linux currently lacks tools for performing filesystem checks on boot to clear things like a dirty filesystem state; typically caused by not ejecting the drive cleanly under Windows or sudden power-loss events on Linux when power is pulled. So if that state occurs and the drive doesn't mount, the state can only be cleared under Windows using chkdsk.exe. This issue will go away with Linux 7.1 in future LE releases when Linux gains the missing tools.

  • External USB hard drive not showing up in Libreelec.

    Quote from hy_tek

    My Raspi 3B+ just updated Libreelec on its own to version 12

    That's a false statement. LibreELEC will auto-update to a new minor release, e.g. 12.0.0 to 12.0.1, but never to a new major release, e.g. 11.0.0 to 12.0.0 or 12.0.0 to 12.2.0; so either someone manually updated using the LE settings add-on, or manually updated by downloading the newer release image file to the /storage/.update folder and rebooting.

    In LE 12.0+ the NTFS filesystem drivers changed from the userspace NTFS-3G driver to a native in-kernel driver and this is sensitive towards a dirty filesystem state; typically caused by not ejecting the drive cleanly in Windows before moving over to the RPi or by hard power pulls on the RPi. Linux will not mount a dirty filesystem to prevent data loss. Unlike native Linux filesystems like EXT4 which can be checked/fixed on boot using "fsck" there are currently no equivalent tools so clearing a dirty filesystem state can only be done on Windows using chkdsk.exe.

    So, try clearing the dirty state on Windows first. If this doesn't work something else is up/bad/broken with the drive and we'll need to see the system log (not Kodi log) to look for error messages. If it does work but the issue keeps repeating, you can revert to the NTFS-3G driver by installing the NTFS-3G driver add-on from the LE add-on repo.

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

    Code
    2026-02-26 20:08:45.355 T:2649     info <general>: [display-info] make: 'LG Electronics' model: 'LG FULL HD'
2026-02-26 20:08:45.404 T:2649     info <general>: Found resolution 1920x1080 with 1920x1080 @ 60.000000 Hz

    I haven't looked at the script(s) involved in Intel GPU capture, but I suspect running "getedid create" without first running "getedid delete" to remove the config doesn't overwrite the existing capture files. The log lines above^ are from the kodi.log output and are the same as the previous logs shared (only a single 1080p mode, etc.) hence there is no change in Kodi behaviour.

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

    Quote from librecuba

    I can't help but wonder why the config.txt approach was removed in the first place.

    The "old" video pipeline was 100,000 lines of downstream code that relied on closed-source magic in firmware and both the open-source (downstream) code and closed-source firmware blobs would never be accepted upstream. RPi4 was in the early stages of development and would need another large chunk of all-new downstream code and Raspberry Pi devs finally realised their long-term technical debt from hoarding ever-more downstream code was unsustainable. Team Kodi helped the decision to rework the codebase and start upstreaming it by stating Kodi on Linux would be moving towards open-standards and would remove all vendor proprietary decode methods (including OMX, MMAL) from its codebase as part of it's own efforts towards sustainable code.

    So RPi devs did the right thing and reworked the video pipeline to follow modern Linux DRM standards, moving most (but not all) config.txt capabilities out of closed-source firmware into open-source kernel code, and open VL42 decoding approaches. RPi4 had some delays and ended up shipping in the middle of a Debian release cycle, so some "old methods" code was slung together to coexist with the current RPi2/3 oriented Debian codebase, and the changeover to "new methods" was timed for the next Debian and RPiOS release about six months later.

    Other than the usual "old is good, new is bad" grumbles that accompany all change it's been a fairly painless switch. Your specific scenario is one of the few (but niche) casualties of the change. I would read up on what the AVR can do as most have the ability to mirror outputs and advertise their own HDMI capabilities, but that's your call..

  • 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?