Are you running the latest NUC and LSPCON firmwares? - This normally needs updating from Windows.
Posts by chewitt
-
-
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
-
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).
-
Code
- 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.
-
Nobody else has reported anything similar and I'm not seeing anything on an N150 box. Some major changes were merged around 11th May so we are interested to know if a nightly from the first week of May (before them) results in a different experience? You should also ensure the N100 device is running the latest BIOS and LSPCON firmware; most devices will need to run update tools under Windows which can be inconvenient, but it can be important. Also provide the output from "pastekodi" with Kodi in debug mode with bug reports so we can see what's actually happening and/or look for interesting error messages.
-
If you look at the filesystem 'Generic' is an alias of the 'OpenGLES' device
-
No further action from us then.
-
I have not seen anyone posting that they can play the specific testfiles I reported I can not play
You've waffled on about files that don't play, but haven't named or given us the specifics of any actual files. So one of the reasons we would like to see a debug log is to see the filenames (and other useful information missing from your report).
I'm able to play all the HDR test media I have which is normally playable (broken files remain broken) on RPi5 and RK3588 boards and an N150 Intel box that all run the reardonia patches.
No debug log = Nothing further to investigate
-
-
If you're using that to play content you need to read the Kodi wiki sections on Videos (GUI item) and Library views/scraping.
-
Kodi Settings > File browser. If you have a favourite backup you can copy files to an inserted USB, or use the delete function to clean up files you don't want from /storage/backup. Or learn some rocket science and use an SSH client to log-in to the console and delete created backup files from /storage/backup.
-
Hope this helps for now .
Nope. Please share the debug logs. These will hopefully allow us to deduce what configuration and code-paths are being used, which is not apparent from the blah blah HDR/DV blah artefact blah waffle.
-
The kernel loads i915 or xe drivers which detects the hardware capabilities and exposes them to userspace through VAAPI which is the UAPI. Kodi detects codec capabilities using libva (which uses the UAPI) at startup and exposes appropriate codec on/off controls in the GUI, but defaults to enabling all supported codecs; which means Kodi instructs FFMpeg to VAAPI decode and FFMpeg will also use the UAPI to query further capabilities and either hardware decode or fall-back to software. VAAPI is native to AMD and Intel, and is also currently used with nVidia through the elFarto VAAPI shim, although that will be superseded with Kodi NVDEC support in the future. In the future we should be able to drop most of the VAAPI code within Kodi as FFMpeg evolved and our code is now mostly duplicating capability that exists in FFMpeg; so we offload more to FFMpeg and simplify Kodi.