Posts by chewitt

ConnMan is not quite as strict as the kernel, but maintainers prefer patch descriptions with an imperative tone, so if there is another iteration of the patch I'd change this:

During interface teardown, the GSupplicantInterface resources were not being
properly canceled, leading to a socket file descriptor leak. This patch
ensures that g_supplicant_interface_cancel is executed safely when the
interface is removed.

To this (but with correct line wrapping):

During interface teardown GSupplicantInterface resources are not properly canceled leading to a socket file descriptor leak. Fix this by ensuring g_supplicant_interface_cancel is always executed when an interface is removed.

NB: there appears to be a stray line-delete in the patch:

--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2740,19 +2740,17 @@  static void interface_removed(GSupplicantInterface *interface)
 	DBG("ifname %s", ifname);
 
 	wifi = g_supplicant_interface_get_data(interface);
-
 	if (wifi)
 		wifi->interface = NULL;

If you have an account on patchwork it would be good to mark earlier iterations of patches as superseded so maintainer tools (and thus maintainers) can ignore them.

To the original question: I'd prefer to see the patch merged and package bumped than place 'known bug' info in the wiki.

As a general rule we have no problem picking patches submitted to mailing lists into LE kernels as there's a visible commitment to upstream things and we'll be able to drop patches in future kernel bumps. This is all good and normal.

For boot things, proper u-boot support would be desirable. If the box has a signed bootloader? then that becomes difficult, but I'd look to solve those kind of packaging issues via amlogic-boot-fip and projects/Amlogic/bootloader/{install,release,mkimage} scripts than do on-box assembly with emmctool. I have no knowledge of these boxes though. I did see there's no SD card interface so I guess you are booting from a USB stick?

Tvheadend (server) supports IPTV sources, which are then visible in Kodi as channels via the Tvheadend PVR client addon. Q's on the topic are probably best directed towards the Tvheadend forum; although be mindful that the developers there (as here) have rather low or no interest in helping people with pirate IPTV sources.

The kernel drivers need to evolve to handle yuv420p10le and AFBC compression; which is a rather non-trivial task requiring human developer experience in media drivers and proper Amlogic silicon knowledge to ensure correct architecture. I've tried pointing the latest generations of LLM tools at the problem, but even Claude Fable quickly descends into AI-slop generation when trying to port things from the proprietary Amlogic BSP codebase. Amlogic are working on entirely new drivers and allegedly new DRM code; but this will focus on their newer chips (although they have promised to back-fill support for older ones) and due to their inexperience with upstreaming the progress is glacial.

Kodi V4L2 decoding does not support per-codec enable/disable and the whole point of V4L2 decoding is a clean implementation that avoids the typical Android approach of band-aiding userspace apps to workaround flawed kernels. If the kernel side works the need to disable things goes away.

NB: GXL chips like S905X/D/W/L/etc. support 10-bit decoding and processing inside the chip, but only 8-bit output, so these boards always have some visible banding. The dithering options recently added to K22 seem to help a little with this.

TL/DR; I lack the developer skills and knowledge to fix the problem and there's not really anyone anywhere working on the staging driver to fix its many problems (it has some deeper architectural issues once you get to newer generations). Until that changes, it is what it is, sadly.

raspberry_kan If intending to upstream the device-tree to the kernel:

* Drop most of the comments from the dts; discussion should be done in a cover-letter or commit description, not code

* Commits need a 'Signed-off-by' with a real name/email

* You need to update bindings with information too; learn to run a bindings check against the dts to find errors

Please note that emmctool support is intentionally for devices that have upstream u-boot support. I'm not inclined to accept any changes that manipulate vendor boot code; there are too many opportunities for 'bricking' devices.

There is no support for SSV6051 chips on a modern Linux kernel. Armbian devs hacked something together for Rockchip boards but the hacking simplified the driver by removing all the code associated with Amlogic hardware, so while it might read like an option in Google results it's not usable; and even on Rockchip hardware the driver is dreadful.

TL/DR; these days upstream Realtek USB WiFi chip support is decent so lots of good dongles available.

Answered in Supported video cards

NB: While LE13 is using the 580.xx driver we'll need to bump to the latest driver to gain coverage of newer nVidia cards at some point, and the next-latest 595.xx series drops support for everything before RTX cards. Intel/AMD avoid the whole 'sliding window of support coverage' we see with nVidia cards.

The libnfs maintainer bumped to 7.0.1 to ensure the already-merged fix for the issue we hit is picked up by mainstream distros that generally prefer tagged versions. LE is also bumped to this now; so problem solved (twice). Thanks for testing.

Quote from Luvide

okk so it turns out it really was the splitter!

We'll feign surprise at discovering that

Quote from atirage21

Only for information about HW from Linux version 6.19.0

To be crystal clear, I have zero interest in bug reports against this kernel as it's about to be superseded with the 7.2 kernel as used in the images from my test shares. Dealing with temp things is a low priority to investigate, so repeatedly posting the same "still not working" post is just becoming annoying. I also haven't read the AI-slop 'guidance' posted, because Gemini is total garbage.

It's not changed since OpenELEC days and is still supported:

LibreELEC.tv/packages/sysutils/busybox/scripts/init at master · LibreELEC/LibreELEC.tv

Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.

github.com

This will get merged later and should be in nightlies within 24-48h: https://github.com/LibreELEC/LibreELEC.tv/pull/11711

Some analysis of Kodi and libnfs by Claude suggested https://github.com/sahlberg/libnf…d476e423ae0fff9 added between 6.0.2 and 7.0.0 causes the problem, and is solved in https://github.com/sahlberg/libnf…8e88ea7e15c3229 which has been merged since 7.0.0 that we bumped to; so please test https://chewitt.libreelec.tv/testing/LibreE…-12.95.1.img.gz which bumps libnfs to the current latest commit to include that, and report back.

Quote from eightball70

On my Synology NAS the max. NFS protocol is set to NFSv4.1 and it‘s not working after the libnfs update.

Is the Kodi NFS client configured for NFSv4? - the default is NFSv3

https://chewitt.libreelec.tv/testing/.Libre…-12.95.1.img.gz is a current LE13 nightly (ignore the odd version) with the recent libnfs bump reverted. Test and report back.

That sounds like an insufficient response/timeout value in the DRM code somewhere. I'd look, but i915/xe have a bazillion lines of code so it would be needle-in-haystack for my ignorant eyeballs. If you have time/access (and importantly, the hardware) perhaps ask an AI tools to look for it?

I'm probably missing some context. What problem is the Denon resync script solving?