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.
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.
2026-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
I'm not aware that we have thunderbolt support enabled in the kernel. You'll need to experiment with a custom LE image that enables whatever drivers are missing (some research will be required).
- We are not fans of discussion on VPN services used to hide piracy or bypass geolocking
- User accounts posting VPN service recommendations will be deleted without warningDoemela I have removed one of your posts as it contained direct links to VPN services providers and read like an advertorial post endorsing a service. There is no problem to support your addon here as long as threads/posts focus on technical issues and remain aligned with forum rules, thank you.
Are builds on your share more advanced, experimental or developed than the current nightly ones for RPI4 for example, for a given date?
The images in my share are normally using a newer kernel and kernel patchset for testing, so you can consider them experimental, but are otherwise broadly the same as a current nightly at the same date/time for overall package states. Unless I'm forgetful the changes in the image should be visible in the amlogic branch in my GitHub repo; diff/compare accross forks to see differences.
