Posts by chewitt

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.

Quote from Thorne

chewitt would this mean that a LE 12.0 build might not have the same issues?

I don't have the hardware so have no personal baseline understanding of what the state of older images is. We don't charge for downloads or testing though, so you can try them.

At the current time "you get output" .. what bit-depth, colourspace and colour-range I've no idea. It's probably not brilliant as we're forced to use the elFarto VAAPI shim until Kodi gains NVDEC support. There are also quite a few things to unwind/redo in Kodi's EGL rendering path to resolve. The x86 world is oriented towards RGB rather than YUV but this isn't an issue as long as things are being done right, i.e. fixing some of the limited/full range issues in the display chain; which is actively being worked on. So no advantages over Intel/AMD that I can see (both suffer from some of the same RGB issues) and I'd still advise anyone considering new purchases to avoid nVidia cards until more of the plumbing has been straightened out.

NB: Support for nVidia now means only GPU's that can use the 580.xx driver series; and we've intentionally held off bumping to the latest driver because that orphans eveything before RTX cards. Current stats show nVidia tiny user numbers on the 580.xx driver, though to be fair we have been telling users to avoid nVidia cards for the last decade so there's an element of "built it and they will come" in-play. I'd expect numbers to increase once there is clear direction on support.

Note that we have previously rejected addition of upower items as they really aren't needed with LE and we seek to avoid "the death of a thousand cuts" from adding bloat. Adding support into the buildsystem to benefit Lakka use-cases is fine; as long as inclusion is configurable from options.

I pushed new test images to my share with Linux 7.0.8 kernel that include the HDMI rework from Kwiboo that's currently on the mailng list. Kodi has bumped DB versions so initial restart after updating might take as the DB's need to be migrated.

The main notable change is BT working on the WP2 box. It turns out we were using the wrong Broadcom firmware; the box runs the chip at 26MHz, the firmware was for 37.4MHz, so once the correct one was substituted it started working.

Quote from kapqa

is it possible to easily convert to a LibreElec Box with Remote or rather difficult?

You can have a look at the image that ilmich releases for older hardware, but that's the sole option (and not guaranteed). There is not much support upstream for the RK3318 chipset (and thus no point in making official LE images).

Screenshots haven't worked (except on X11 images) for a long time. It's a consequence of the zero-copy video pipeline.

Quote from HomerJau

Maybe LE can offer NVidia as a new separate gz package?

Nope. If we claim support for nVidia GPUs it needs to work OOB.

The other option is replacing Generic-Legacy (X11) with an nVidia/GBM image for LE13 to still effect the underlying architectural change but avoid the size-bump for LE13, but we'd want to consolidate for LE14 regardless so it's only delaying the inevitable.

It doesn't matter how old the HiFi bit are; if they sound good, they sound good. IMHO a slim case would be better, but as you said, there aren't so many choices these days, and none are cheap. If it works, don't fix it

The default boot partition was enlarged from 512MB > 1GB last year to accomodate nVidia driver increases over time, and Generic now (since yesterday) supports current nVidia GPU cards hence the sudden size increase.

The fastest workaround is to use the backup function in the settings add-on (captures /storage/.cache|.config|.kodi) and move that off box, reinstall to create a clean instance with larger boot partition, then restore the backup. Beware anything outside of those ^ folders that you also want to preserve. Resizing partitions can also be done using e.g. Gparted on an Ubuntu LiveUSB, but it will be significantly slower (10x slower if not more).

Quote from chall88

The RockPro64 HDMI bridge driver (dw_hdmi_rockchip) hasn't been updated yet. The HDMI bridge initializes incorrectly, causing all HDMI connector-level DRM property writes to fail with EACCES (-13). This is also why Kodi has no display on LE 13 RockPro64, Kodi uses KMS atomic commits too and hits the same broken bridge.

There are patches on the mailing list from Kwiboo to address this:

Rockchip SoC list - Patchwork

Rockchip SoC list - Patchwork

I will rework the rockchip patches to include them over the next week, although this will likely cause a regression since the colour related changes that are also needed for parity with older RK images (on older kernels, before the old patches bit-rotted) aren't available just yet. Soon hopefully..

Installing the Tailscale addon from the LE repo would be easier than all the above suggestions. No need for Docker containers or not-existing flatpak’s.

Just stop Kodi and clone the /storage/.kodi folder to /storage/.kodi-old then update to LE13. It will reuse existing config and you can easily revert back by swapping the folder around again.

LE13 now has support for flatpak add-ons with the Chrome add-on experience where Kodi is stopped, the flatpak app runs, and when you exit the app Kodi is restarted. We already added the SteamLink flatpak. We'd prefer to see a Moonlight flatpak add-on (assuming it works) as this would have less maintenance and faster compile than dealing with Qt6 from source.

You could also investigate the LEIoT distro which coexists in the buildsystem as the base for a more minimal image. LEIoT drops all the background plumbing for Kodi (which you're probably not using) with a base image around 85MB in size (including Docker). You could drop docker and add moonlight-qt to ADDITIONAL_PACKAGES+= and see what happens or leave it and package the Qt6 things you need into a container (or be lazy and pull someone else's) .. there's lots of options.

NB: I'd suggest creating your own $DEVICE in the buildsystem else future changes we push will trample on yours in a rebase. I plan to drop current Rockchip devices after LE13 and reconfigure the buildsystem to have two new ones; a single 'arm' image (RK3288) and single 'aarch64' image (RK3328 thru RK3588) using a common kernel/patchset.

If you are granting access to NAS shares only to specific IP's and the RPi moves around the DHCP scope, you could:

• Configure a static address in the RPi and then allow that address on the NAS
• Create a DHCP reservation in the router for the RPi so it is always dynamically assigned the same address
• Create credentials to access the shares and avoid the need for IP blocking

IMHO using a DHCP reservation (makes SSH access to the RPi consistent) and also using credentials and basic access controls to manage access to shares is the winning combination. From a security perspective IP blocking is a fairly blunt instrument.