Posts by chewitt

If you look at the filesystem 'Generic' is an alias of the 'OpenGLES' device

No further action from us then.

Quote from houser

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

RPi throttled=0xe0008

This ^ means overheating with active throttling, which will impact on playback performance, so investigate why that's happening. You can also drop the 4096x2160 resolutions from the whitelist as they won't be used; leave only the 3840x2160 ones.

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.

Quote from houser

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.

"We are not fans of discussion on VPN services used to hide piracy or bypass geolocking"

^ a reminder of forum rules. The first post was informational. The second, while it remains discussion of a technology more than a specific service, is heading in the wrong direction. NB: Also not fans of AI generated posts which are always obvious from the way things are over-structured and decorated.

The LE settings add-on backs up only /storage/.cache|.config|.kodi .. and nothing else; the design assumption is that covers all the essential config items to restore to another device, but not media which is normally too large to duplicate/store. The backup files are saved to /storage/backup if you want to move them off-box or delete them to free up space.

The backup addon in the Kodi repo will be more flexible .. but is someone else's problem to educate and support on.

If you have other Linux devices you can save to, installing the network-tools addon and using rsync from a cron task is probably the easiest approach to an automated backup.

There are 3-4 different chipsets used in most USB-Ethernet adapters and these should all be supported. If a device is not working (and you cannot get the NUC online) you need to dump the log to a USB drive "dmesg > /var/media/USBDRIVE/dmesg.log" (change for whatever the path to the device is) and then upload/pastebin the log so we can hopefully see what the issue is. You won't get a "buy this one!" purchase recommendation because most adapters are cheap/no-name branded and manufacturers are in the habit of changing the chips inside the adapter between different batches/versions of the device.

If defaults are configurable and should be corrected, please find a way to change the defaults.

The kernel is something that moves forwards continuously and relentlessly so the adage "If you stand still, you're actually moving backwards" applies in a big way and because (for good reasons) people became inactive for a while a whole heap of WIP changes got parked for a while. I don't think there's a single series, it's more a case of "a little bit of everything" as the kernel evolved.

Quote from adam.h.

Honestly, I'm not sure this brings value for you - maybe it does

Several of the project staff have experience with Yocto/OE for other projects and work requirements and it has inspired changes to our own in the past. It does benefit from having far greater build capabilities, but it's also quite a bit more complex and is thus less accessible to the type of hobbyist developers we attract (for our hobbyist distro) and that's long recognised as something important for the project and the ecosystem of forks that surround us. In that sense it's an interesting exercise to see, and kudos for getting things as far as bootable images, but I think we're unlikely to change the buildsystem we use.

Things I'd like to see done (which we mostly know how to do, but time..) is moving to a reusable toolchain as this would massively reduce the total time required for building nightly images with CI and would probably allow us to test-build PR's. The uboot_helper script could also be expanded to more of a build-matrix function; e.g. https://github.com/LibreELEC/LibreELEC.tv/pull/6427 which has bit-rotted a little as people's lives changed and became less active. We are laggards at adopting things largely due to being a bunch of hobbyists and the desire to not fcuk up something that basically works

It's not an issue for YUV media to be converted and output in an RGB colourspace as long as it's done correctly (there are specs and broadcast standards for doing it). It's far more important for Kodi to open a proper 10-bit plane and use the correct buffer types for the media to avoid ffmpeg silently downsampling YUV 4:2:0 10-bit to 8-bit (the default on Intel hardware since forever) and similar bad things. Have a read through the list of PR's here https://github.com/xbmc/xbmc/issu…hor%3Areardonia (merged) and https://github.com/xbmc/xbmc/issu…hor%3Areardonia (pending, but patched in that image) for a more detailed understanding of the issues being resolved. TL/DR "It's RGB" is rather missing the point

I'd be interested to know how you see this image behave? It has a whole heap o' changes including proper 10-bit and 4:2:2/4:4:4 support. https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz

Your post is rather lacking in details and it's not clear what the purpose of that lib is ..

I'm aware the HDMI chain on RK3288/RK3328/RK3399/RK3566/RK3568 (all chips that use dw-hdmi, not dw-hdmi-qp) is probably a little borked at the moment. The older patches (2018-2022) have now bit-rotted to the point where things are breaking on newer kernels and need reworking. Kwiboo is actively working on that and he's started to send replacement patch series to the kernel mailing lists, but the total number of patches is huge (150+) and right now only ~3/8 series are submitted. I plan to rework our kernel patchset this week to drop older patches and start including them, but this will be a "two steps forwards, three steps backwards" move as Jonas is (re)building the base functionality first. Older patches that add e.g. 4K/HDR support are unlikely to be useable so I expect capabilities to regress until more of the rework lands. Older LE releases with older kernels/patches before breakage are probably more functional on the above hardware at this point of time.