Posts by chewitt

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)

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.

I had a quick look over https://github.com/libretro/Lakka….1/projects/L4T and it still appears to be using a legacy vendor kernel and many device-specific-version packages overriding the higher-version packages in the buildsystem, and there are firmware blobs littering the buildsystem instead of being hosted in packages.

For general guidance:

• Use upstream (or near-upstream) kernels; if hardware is not upstream, do work to change that
• Use upstream package versions; if hardware needs an old package, do work to change that
• If you have patches; upstream the patch else you accumulate technical dept and/or get stuck with old packages
• Never host firmware in the buildsystem; always offload it to a repo and source the package

In OE days and early LE when everything except x86_64 kit required some form of downstream codebase and our active team was 4-5x larger, tolerance for "look mum, it booted" levels of codebase maintainbility were also larger. These days the project team is smaller, and we learned the hard way that downstream stuff is generally a complete turd to sustain in the long term. So current LE champions upstream development and generally only accepts downstream items when there is clear line-of-sight on upstreaming activity and we have confidence in being able to drop them in future kernel/package bumps. This actively limits the hardware that we choose to run on, but we've always been okay with that, and we're constantly looking for things we can prune/drop to keep the codebase lean and oriented in a forwards direction.

Lakka inherently cares more about older hardware and has always had a more hobbyist tolerance for niche devices that need a heap of downstream kernel/firmware/package things to make a device boot and run. As Lakka only needs 2D graphics to work, it's also a lot easier to get things working than LE which needs a much higher level of media support.

IMHO current Switch support (dependent on nVidia who is remains focussed on their BSP codebase more than upstream) is still too far downstream for LE to accept, and support should focus on and be maintained in Lakka.

Quote from mintsoft

The Kodi crashlog doesn't really have anything interesting, but for completeness

In future "completeness" means sharing the whole log to include all the useful information that's ommitted when people try to be helpful and share incomplete snippets

Start with testing the latest LE13 nightly as there are numerous interesting changes recently and there will be no more 12.2 releases; meaning even if we did investigate and find something the fix goes only into LE13, so best to start there.

I never put devices on static addresses, I use DHCP reservations in the router so that what has what is easily seen in a single place.

LE has a firewall. It's off by default, but if enabled it probably blocks ICMP (ping) requests.

I'm confident there is no LE software issue here. It's either environment or PEBKAC

Honestly no idea what you're talking about

LE doesn't mind if Lakka things are discussed occasionally, but LE has zero Switch support (and isn't looking to change that) so it's not really on-topic for here. Perhaps better to discuss in Lakka/Retroarch forums?

I only suggested you use AI tools to explain things in a user-appropriate level of detail.

If you also want to make AI based Kodi feature-requests (the technical developer term for them is Al-slop) those need to be directed to the Kodi developers in the Kodi forum. LE only packages Kodi, we engage with them to support development, but we aren't often responsible for changes and this is 100% not in our scope of activity. Kodi features should work across all possible platforms to be considered. In this case changes would need to work on "Linux" and not be Broadcom specific. Any changes that target a single silicon vendor will be dismissed on principle.

If you haven't already figured out that the LE codebase is not the one to be concerning yourself with, I suggest you go poke around in Kodi pull requests to look for interesting things. If you find something, pay attention to the extensive PR summaries, individual commit descriptions, and detailed code comments.

The list of open ports in the nmap scan results suggest 192.168.1.17 is some kind of Linux NAS or appliance device; it is not a good match for an LE device. I think you have an IP address conflict happening. Two devices claiming the same IP would probably explain some of the behaviours you are seeing.

The current TigerVNC add-on appears to be compiled against X11 libs so I doubt it runs under Generic, and it probably runs into the same zero-copy video pipeline issues that all the Ambilight setups (that depend on copying buffers that can no longer be copied) enounter under GBM/V4L2. If my guess is correct the add-on will need to be dropped when we remove X11.

The flatpak add-ons require Generic (GBM) and will not run on Generic-Legacy (X11). The flatpak changes are an essential step on the journey to discontinuing the Generic-Legacy image; along with changes that enable the few remaining nVidia cards that can work in LE to use GBM/VAAPI via the elfarto VAAPI shim until future GBM/NVDEC support lands in Kodi. Unless you are "blessed" with an nVidia GPU and thus forced to remain on Generic-Legacy, you should switch to Generic.