Posts by chewitt

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.

Fixes for settings add-on bugs are always welcome. We're pretty slow at merging things there as none of us are Python devs, but as long as you're patient we'll be able to find someone to assist.

Update to a current Generic LE13 nightly, install one of the (new) flatpak browser add-ons, use the browser to exit Kodi and access Netflix in the browser, then exit the browser to restart Kodi.

Running WebOS apps is not possible. Same for Android APK's, etc.

If you are using Tvheadend, some help with reviewing the DTV Scan Tables that are bundled with the app would be appreciated!

For more info:

DTV Scan Tables - Your Help is Needed!

One of the items on the project #todo list is updating the dtv-scan-table files we ship with our .deb and .rpm packages to accelerate new installations. User...

tvheadend.org

Combine "tvheadend" differences and unmerged PR's into "linuxtv" upstream branch by chewitt · Pull Request #167 · tvheadend/dtv-scan-tables

This PR exists to provide a simple means of diff/comparing the combined and tvheadend branches. It is the outcome of tasking Claude to walk the current…

github.com

I dropped that patch from my images in the last week as there are multiple reports of it making no difference

However, earlier today this test/guess was merged https://github.com/LibreELEC/LibreELEC.tv/pull/11322

The RPi4 and RPi5 images in my test share are now updated to include that, and it should be in nightlies over the next 24-36h

Quote from wyup

¿Source evidence?

popcornmix has good sources. If he says this was the method used, it was the method used.

Revised link: https://www.cs.utexas.edu/~fussell/cours…ll/Mitchell.pdf

(an exhausting 10 seconds of Google search time on "mitchell netravali filter" were needed to find it)