Posts by chewitt

Let's go back a few steps. What hardware are you trying to boot, and how are you booting it?

mglae That's a solution to a different problem. There are Rockchip vendor tools that allow you to flash an [Android ROM] image direct to eMMC using a USB cable, but they use proprietary packging so our "dd" based ".img" format cannot be used with them.

I'm not aware of any tools to convert our img to the format used with vendor flashing tools. You can remount the boot partition with mount -o remount,rw /flash to edit extlinux.conf, but we are using u-boot that supports boot=UUID and extlinux.conf is using UUID so that should work as long as you don't have SD/USB media created from the same image attached (as those will also match the same UUIDs). You shouldn't need to change the conf.

Quote from ICU001

I need to use LE12 , is there any solution to fix this problem?

You either continue using the LE13 image, or self-build an LE12 image with a current/newer kernel that supports the GPU.

Quote from Da Flex

You can disable auto-update.

Which is irrelevant as my builds are dev builds that do not support auto-updating.

I've set one via the UI and I've no idea where it's been stored; but not in cleartext in guisettings.xml so I'd guess it's somewhere in the MySQL DB that my install uses, and right now I don't have the option to go poking around in DB tables to check. However, if it can be set via guisettings.xml the format is probably be the same as the webserver username, so crib that and experiment. If no difference, revert the change and no harm is done.

There are no config.txt or cmdline.txt options to disable video output. You can disable the entire DRM connector, but that disables audio too as audio capabilities are derived from EDID/ELD data that depend on an active connector.

Selecting passthrough audio does not disable video for an HDMI port; hence that is not documented.

Did you attempt the force_turbo and core_freq config.txt changes as popcornmix suggested?

When you enable the webserver in the UI, a webserver password must be set first, else it will not enable.

Quote from jim_p

Third option is to use one of your images, since they do contain the driver. But that means using a dev version of le, and very frequent updates.

Even if we bump Kodi versions and that contains an API bump that requires an add-on version increment, the existing "dev" image will remain working in 99% of cases. You're the person who dictates how often updates are done.

Done

The standard thing to try with CEC issues is "turn off and disconnect everything, go have a cup of tea or wait a while, then reconnect and power it all back on again" .. but if that doesn't resolve the issue I wouldn't expect any development against that codebase.

Others normally involved in RK matters have been offline for a while due to other commitments, but DHL should be delivering some boards to me today, and I can start the task of understanding all the dependencies for that and other series needed, and figuring out what's needed on the packaging side to make some images.

Boot from SD card, download/transfer the same image you wrote to the SD card to /storage, then ensure any existing partitions on eMMC are unmounted, then write the image to the eMMC device using dd, then shutdown and remove the SD card.

Scraping sites come and go over time for no reason other than the wind starts blowing in another direction, or because sites switch their business model and start imposing restrictions that don't make sense for Kodi trying to sustain milllions of users. The default was set by Kodi not LE and if that needs to change, Kodi should change it, not LE.

All the scraping sites support end-user input in some form. If the content is wrong, submit changes. If nobody submits changes, it remains wrong. Or do the lazy-user approach and wait for someone else to do it, but that might involve a long wait.

The arm > aarch64 change breaks binary add-ons, so you need to uninstall those on RPi4 first (retaining their settings) and then manually download the RPi5 image to /storage/.update and run "touch /storage/.update/.nocompat" then "reboot" to start the update process. LE will reboot (using the RPi4 kernel) and update using the RPi5 files. When it reboots after updating, you pull the power and transfer the SD card to the RPi5 board and it should then boot up fine. Once at the Kodi home screen you can reinstall aarch64 versions of binary add-ons. Non-binary add-ons don't need to be touched.

Update to an LE13 testing image. Support should be enabled in the kernel there.

========== kmsprint ==========
Connector 0 (189) HDMI-A-1 (disconnected)
  Encoder 0 (188) TMDS
    Crtc 0 (82) [email protected] 148.500 1920/88/44/148/+ 1080/4/5/36/+ 60 (60.00)  
      Plane 0 (32) fb-id: 211 (crtcs: 0) 0,0 1920x1080 -> 0,0 1920x1080 (C8   RG16 XR24 XB24 AR24 AB24 XR30 XB30 AR30 AB30 XR4H XB4H AR4H AB4H YUYV YVYU UYVY VYUY NV12 P010 P012 P016 Y210 Y212 Y216 XYUV XV30 XV36 XV48)
        FB 211 1920x1080 XR24
Connector 1 (199) HDMI-A-2 (disconnected)
  Encoder 1 (198) TMDS
Connector 2 (203) DP-1 (disconnected)
  Encoder 2 (202) TMDS

This ^ (at kernel DRM level) shows that there is no HDMI device connected.

2025-07-09 16:41:30.014 T:1227     info <general>: GUI format 1920x1080, Display HDMI1: 1920x1080 @ 60.00Hz

This ^ (from kodi.log) shows something being connected to HDMI1.

Kodi detects audio properties from the EDID/ELD data on the HDMI connection. It's weird that the kernel is not seeing any device connected but Kodi is still finding properties from somewhere when it starts. Regardless, there needs to be a functional audio sink for playback to work correctly as audio (in media with an audio track) is rather fundamental to media playback. Kodi is unable to find a working AE (AudioEngine) sink (cannot open a playback device) hence things go wrong.

Check and change HDMI cables and ports on both device and TV/AVR if possible. See what happens. Also use local media for testing in case there are lurking UPnP issues.

Quote from myksto

I tried to use hdparm in autostart.sh with this command: "hdparm -S 0 /dev/sda2" and also "/usr/bin/hdparm -S /dev/sda2" but with no luck: if I pause my watching, HDD spins down, always.

The first example should fail because the script is not providing the full path to hdparm and is addressing a partition not a disk.

The second example should fail because the script is providing an incorrect path to hdparm and addressing a partition not a disk.

Even if you corrected to /dev/sda as per my previous suggestion, you're still going to fail on the first points above.

The correct path is /usr/sbin/hdparm not /usr/bin/hdparm