I don't see a "throttled" warning at your log, so I don't think it's a PSU issue.
The "throttled" message would be a thermal issue not a PSU issue. You're thinking of "undervolt" perhaps.
Posts by chewitt
-
-
If you move the dongle/remote combo between RPi4/NUC systems does the problem follow the move? .. i.e. is it a specific dongle having the problem or all of them?
On the current system; with one of the USB drives moved you can move the dongle from USB2 to USB3 ports. Any change?
-
- Are the two USB drives powered from the USB ports on the board or they have external PSU(s)?
- What is 5V/?A spec of the PSU?
- If you remove one of the drives does the remote appear reliably?
- If you scan the bus with lsusb -tv is the remote USB dongle listed; and does the remote now work?
If you have two drives powered from the board my hunch would be that when the board is booting and everything is in an active state the drives can pull enough power to result in the remote USB dongle not receiving enough to power on. This is probably a borderline case so it might still work occasionally. If you then remove/reconnect some time after boot the board is now in a less active and more power-stable state so the remote USB dongle reliably works.
If the hunch is in the correct direction, perhaps using a higher rated PSU might work, e.g. the 5V/5A spec for an RPi5. Or connecting the drives to a powered USB hub, or if one of the drives has as USB 'Y' lead (to draw power from multiple USB ports) connect the non-data plug to an external USB phone charger to reduce power draw from the 4B board.
-
Double-check that you are using a current nightly. The latest LE13 images are at the bottom of the page not the top; older images will probably use a repo version that no longer exists on the server.
If that's not the issue, you need to investigate whatever local-to-your-install networking problem prevents the RPi5 from connecting to the repo (which is live/accessible). If you are using WiFi ensure "wait for network" is enabled with a long enough delay.
-
(re)boot, leave the OS a couple of mins, then replug the device, SSH in and run pastekodi and share the URL.
-
No idea what the issue is (and you haven't provided debug logs to help the guessing) but LE12.2 is a dead codebase so bump to a current LE13 nightly and move forwards from there.
-
-
how can I find that out ?
If the panel advertises 4K modes it has 4K (or more) pixels. If you send it a 1080p signal the internal processor upscales 1080p to the native 4K panel resolution. It does that better than Kodi (and with zero load on the HTPC). Or you have a magic screen that somehow changes its pixel count when you send it a 1080p signal
-
Sat-TV isn't upscaled to 4K (only to 1920x1080) !
Yup, Kodi upscales to 1080p and the TV upscales 1080p to the native 4K panel resolution. The TV will show that it has a 1080p signal but there are always physically 4K pixels in the screen, no?
-
The TV panel is 4K native resolution so the TV has a ton of advanced scaling capabilties. Kodi can also upscale, but they are not as advanced as the TV's ones. So run the GUI at 1080p, allow Kodi to upscale SD media to 1080p, but allow the TV to handle upscaling of 1080p to 4K as it will do a better job.
-
- Remove i915.force_probe=!a7a0 xe.force_probe=a7a0 from kernel boot params
- Add video=HDMI-A-1:1920x1080M@60D to kernel boot params
- Configure Kodi to run the GUI at 1080@60
- Configure EGL/VAAPI (not D2P, not DRMPRIME)
- Configure the whitelist for 3840@60/59.94/50/29.97/25/24/23.976 and 1080@60/59.94/50/24/23.976
- Configure adjust refresh (start/stop)
- Configure allow rate doubling
Then play some media and pastebin another debug log.
-
RPi3 hardware is 64-bit capable but media drivers (inherited from RPi1/2) are optimised for arm and on the advice of RPi devs we continue to ship RPi3 as an arm image. RPi4/5 run different drivers that are written and optimised for aarch64 or where the small performance difference doesn't hurt.
If you disable auto update mode (which only auto-updates minor updates) in the GUI and then manually choose to update to LE12.2, the file downloaded and used for the update is the .tar file. If you download from the website the .img.gz file can be used.
-
Are you running the latest NUC and LSPCON firmwares? - This normally needs updating from Windows.
-
Don't remove; add the missing ones. This applies to non-HDR use too: https://wiki.libreelec.tv/configuration/4k-hdr
-
Please retest with the Generic image here: https://chewitt.libreelec.tv/testing/ .. it has some additional changes.
-
Current LE13 nightlies include a patch that forces 10-bit output which should workaround the audio dropout problem.
-
Current status of anything I'm working on is in my public GitHub repos. Current status of anything Amlogic is working to upstream is on public kernel mailing-lists. All the patches are tagged and well commented.
-
Intel hardware should be using EGL/VAAPI rendering. We probably need to do some appliance.xml fiddling to hide other options.
Code2026-05-30 14:02:18.372 T:858 debug <general>: [WHITELIST] whitelisted modes: 3840x2160 @ 60.000000 Hz 1920x1080 @ 60.000000 HzNB: ^ this is bad configuration when you have all the normal rates available from the TV
