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.
Posts by chewitt
-
-
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.
-
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.
-
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).
-
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:
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.orgCombine "tvheadend" differences and unmerged PR's into "linuxtv" upstream branch by chewitt · Pull Request #167 · tvheadend/dtv-scan-tablesThis 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
-
¿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)
-
For a while Generic has been using OpenGL, but in the last week was switched back to using OpenGLES. This requires rebuild of all addons that link to GL/GLES so the repo version was bumped, which is a global change for all hardware we support. You have then updated from an older nightly to one that requires addons matching the new/bumped repo version. Kodi detected the installed addon no longer aligns with the required repo-version and either it flagged that before checking the new repo for an updated Tvheadend addon, or it checked and the addon was not available (as it takes us some time to build all the addons and publish them again) or something of that nature. Worst case you might need to force a repo update in the Kodi GUI to ensure the addon updates to a new compatible version and then reboot to use it.
