Posts by chewitt

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

    RPi5 boards will not boot from NVME devices without some additional configuration. If booted from LE on an SD card:

    Code
    RPi5:~ # mount -o remount,rw /flash
RPi5:~ # nano /flash/config.txt

dtparam=pciex1              <= add to bottom of config.txt
dtparam=pciex1_gen=3        <= optional, enables faster speeds

    Next you have to tell the EEPROM on the board to change the boot order:

    Code
    RPi5:~ # rpi-eeprom-config --edit

BOOT_ORDER=0xf416           <= change the BOOT_ORDER line to this
PCIE_PROBE=1                <= might be needed with older HAT devices (try without first)

    However, if the goal is to boot LE from the NVME drive, it needs to be configured with TWO partitions; one for boot files and one to be used as the persistent /storage area. If the drive is currently partitioned with a single partition and filesystem (containing some media) this is easiest done by copying media off the drive, booting LE from SD card, copying an LE image to /storage then writing it to the NVME drive using dd to effect a clean install; and then copying media back to the drive. Resizing and moving filesystems and partitions to avoid the need for moving media around can also be done, but it's not a trivial task to do from the console.

    If you are fine booting LE from the SD card and simply want to use the device as extra storage that's no drama. Run pastekodi and mount | paste from the SSH console then share the URL(s) generated so we can check the drive mounted correctly and see where it mounted within the filesystem; the usual location is /var/media/<label> if the drive is named/labeled or /var/media/<UUID> if there is no name/label and the UUID is used instead.

  • External USB hard drive not showing up in Libreelec.

    Your initial description implied the OS auto-updating from an older LE major version to LE12 and this is 100% not possible. LE (and OE before it) have never supported major version auto-update. I've also checked the update back-end that controls this and nothing has been misconfigured.

    Auto-updating from an older LE12 release to the current LE12 release is of course possible, but in this scenario the NTFS drivers do not change between releases (both use in-kernel NTFS3) so a difference in mount behaviour is unlikedly to be kernel/driver related and more more likely to be the result of a change in drive state; and the perennial problem with NTFS formatted drives (which is not an excuse and happens no matter which driver is used) is a dirty filesystem. The second most popular reason with external drives is the power/current draw on the USB ports/bus and that can be challenging to triage. You can try connecting to different USB ports; ideally placing the drive on a different internal hub to other USB connected devices. If the drive is not externally powered, also try using an external (powered) hub.

    If everything just magically works on an older LE release (using NTFS-3G) this implies the driver change that occured between older releases and LE12, but this is only possible via manual update which you are adamant didn't happen. Regardless; as mentioned in a previous post, you can revert to using the NTFS-3G driver by installing the add-on from the LE12 repo and rebooting.

    NB: Linux intentionally fails to mount at the merest hint of a drive issue to avoid potential damage. Windows generally makes every attempt to keep mounting the drive to keep data available and users happy, and rarely flags any problems until the drive just stops working completely. Hopefully that's not the case though. If you want any further comment run "dmesg | paste" on the LE12 system so we can see what mount failure message are in the system log.

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