Posts by chewitt

I'm back from vacation and there were a few problems in the blind patch guesswork

I've fixed a few issues seen in the RK3588 image that probably affect others too. It seems to be generally working well although I can hear audio dropouts with HBR audio formats (which is nothing new). I need to dig out RK3576/RK3568 boards to run some smoke tests, but I'm still to RK3288/RK3328/RK3399 changes due to lack of hardware.

I've pushed updated a full set of updated images to my test share. Unless people make bug reports I'll be pushing changes to LE13 before the weekend.

NB: I am still looking for someone to confirm that hardware deinterlacing works on RK3288/RK3328/RK3399; i.e. the changes made for RK356X/RK3576/RK3588 haven't broken support on older hardware; so I can submit the driver(s) upstream.

You can clone (cp -R) the contents of /storage/.kodi to /storage/.kodi-working and then systemctl stop kodi and swap .kodi folders around before systemctl start kodi as required for testing and reverting to a working state.

Also please share a Kodi debug log using pastekodi from a release that demonstrates the problem. Share the URL generated here.

wizardknight https://github.com/torvalds/linux…rtw8822bu.c#L12 matches the VID/PID so the issue is probably missing firmware. You can confirm by looking in dmesg. You can also add the missing firmware by following the wiki article, or by sharing the dmesg log so I can see what's missing/required.

I wasn't seeing anything in the logs so glad that you figured it out. The only odd thing I noticed from the logs was that you appear to have everything in the same folder with .nfo files being used to scrape things. That often causes issues with scraping as Kodi expects each movie in it's own folder e.g. smb://server/share/movies/movie(2020)/movie(2020).{avi,nfo,sub} .. but if it works

You're welcome to share links to thinks, but I'm not sure how much actual testing would be done by users due to retroplayer under Kodi still being relatively niche (could be wrong, but this is the impression I still have) so once you are confident from your own testing and the dust has settled on the changes upstream; we can simply merge the extra add-ons at correct versions and bump everything so it's built/available from our repo.

[v3] plugins/wifi: Fix GSupplicantInterface socket leak during teardown - Patchwork

There appears to be a stray line delete after wifi = g_supplicant_interface_get_data(interface); but more importantly the patch description is completely missing. So looks like a fourth attempt will be needed,

I haven't experienced anything similar myself, so no idea what the issue is, but the first step is to update to the current/latest LE13 nightly image (20260817 is available) and test again. If no change, put Kodi in debug mode, scrape media, then run pastekodi over SSH and share the URL generated so we can see the log of what happened.

The historic reason for not implementing the GUI side of those auth methods is simply that nobody on staff has ever had access to networks that used them and thus nothing could be tested; and since OpenELEC days that hasn't changed, and no user with the need for the capabilities and the developer skills to implement it themselves has shown up either. However, to not alienate the very-occasional user who showed up in the forum we left the compile options alone so ConnMan supports those features and config can be hand-rolled over SSH when needed. I do think it would be good to document that process in the wiki so that it's searchable, but (again) that requires a user with practical experience submitting the changes - and so far that has never happened.

I do agree that domestic network kit is ever-more capable these days, but I don't see evidence of Enterprise auth methods being used in the support questions we see in the forum. On that basis (and since we still cannot test things) I don't feel that we need to make the effort. If that changes in the coming years we'll always revisit the requirement.

Quote from wizardknight

I have a known working Realtek 8812BU Wireless LAN 802.11ac USB NIC, but the system doesn't seem to use it

The kernel module (CONFIG_RTW88_8822BU) is enabled in defconfig so the two possible issues are missing USB ID's or missing firmware. You can check if the USB ID's are listed here:

linux/drivers/net/wireless/realtek/rtw88/rtw8822bu.c at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

If no, it's trivial for me to add and upstream them, run lsusb -tv | paste with the NIC attached and share the URL.

If yes, please run dmesg | paste and share the URL so can see what firmware is missing and then pick the file from linux-firmware into the image. NB: You can also add firmware manually https://wiki.libreelec.tv/how-to/add-firmware to confirm the card works.

chewitt@toolbox:~/connman.chewitt$ pwclient git-am 14752333
Applying patch #14752333 using "git am"
Description: [v2] plugins/wifi: Fix GSupplicantInterface socket leak during teardown
Applying: plugins/wifi: Fix GSupplicantInterface socket leak during teardown
error: corrupt patch at line 10
Patch failed at 0001 plugins/wifi: Fix GSupplicantInterface socket leak during teardown
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
'git am' failed with exit status 128

The v2 patch ^ also doesn't apply. I would strongly recommend you configure git send-email so you can generate patches using git format-patch and send them directly from the terminal. Also, when you iterate patch versions it's good practice to place info on what changed from the previous one below the --- marker. See here for an example:

[v3] ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on start/stop - Patchwork

In the case of a single patch where there's no cover-letter to place technical before/after evidence and more detailed background info on the problem, this can be placed under the --- marker too. This is then visible to maintainers reviewing the patch, but not part of the code that's eventually merged.

You will need to send a v3 because the v2 patch is broken. I'd start with a brief apology under the --- marker to explain that it's been a while since you used a mailing list

NB: The linux kernel has ./tools/checkpatch.pl to check that patches are valid from a formatting perspective. I sometimes use that tool against other repos to check for obvious style problems. ConnMan/IWD etc. are not the kernel, but maintainers are also kernel devs so the same/similar standards are expected and it's a good benchmark.

btw, I think you need to check the patch state of the branch you submitted from, because it conflicts with existing code, e.g. this first hunk if (wifi == NULL || wifi->device == NULL) does not exist in current code:

@@ -1014,14 +1014,16 @@  static void
interface_removed(GSupplicantInterface *interface)
 	wifi = g_supplicant_interface_get_data(interface);
 
 	if (wifi != NULL && wifi->tethering == TRUE)
 		return;
 
-	if (wifi == NULL || wifi->device == NULL) {
-		DBG("wifi interface already removed");
-		return;
-	}
+	if (wifi != NULL && wifi->device != NULL) {
+		wifi->interface = NULL;
+		connman_device_set_powered(wifi->device, FALSE);
+	} else {
+		DBG("wifi device linkage missing, executing isolated interface

The current code state was introduced in this patch:

commit 4b3c38ec737f3fc0642cd825471763be570fe02e
Author: Hannu Mallat <[email protected]>
Date:   Mon Sep 29 09:19:56 2014 +0300

    wifi: Set interface pointer to NULL on deallocation
    
    As interface_removed() gets called when the interface struct is being
    deallocated, make sure the pointer is set to NULL regardless of the
    other fields' values in wifi struct.

diff --git a/plugins/wifi.c b/plugins/wifi.c
index 45d88b8e..d18dc6cd 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2284,6 +2284,9 @@ static void interface_removed(GSupplicantInterface *interface)
 
        wifi = g_supplicant_interface_get_data(interface);
 
+       if (wifi)
+               wifi->interface = NULL;
+
        if (wifi && wifi->tethering)
                return;

LE13 is using current ConnMan master plus this series to mitigate the invalid-key issue seen with some wifi connections:

[0/3] wifi: Forgive transient errors - Patchwork

nb: the patch submitted also has style problems due to line length/wrap issues.

Doemela when interacting with mailing lists:

a) If you submit a patch as an additional comment within a bug report (as you have) it will be handled in patch tooling as a comment, and not as a patch. Instead submit the patch to the mailing-list as an actual patch; assume general kernel standards and etiquette for the patch submission. Keep the description brief/simple and use imperative (not conversational) tone. Note that AI generated patches are obvious and a human touch is generally appreciated by maintainers.

b) Once you submit a bug report and start a mail thread on the list always reply to the original message (even if this means replying to yourself) to keep everything in the same thread. If you send further information as 'new' messages these will not be linked in any of the list/review tooling that maintainers use.

c) Never top-post replies; always add information and content inline to the original post or append below the original. Again, this is to keep the information flow sequential in patch/review tooling.

Quote from smf007

The question then is, in order to confirm the issue is with Crocus, is there any way to force Kodi (from Kodi side, not Mesa) to use Linear without having to patch the code?

There's no override mechanism for format selection in Kodi so you'd need to patch code.

Quote from smf007

This seems to possibly be related to a ToDo item in the Mesa Crocus source code.

Link?

It would be useful to see the Kodi debug log output, i.e. pastekodi from a current LE13 development image, please.

Quote from atirage21

And where are published these testing builds ?

The same place they are always published, as referenced in the first post, and repeated numerous other times in the thread.

Quote from atirage21

At my device i have kernel 6.19 with last builds: https://paste.libreelec.tv/islandish-vernice.log

Then you are not running a current development image. This thread has no interest in nightlies and low interest in reports from older images with older kernels.

Quote from ht2tweak

I did add a disp_cap_3d because I've had to do so with CoreELEC and OSMC:

This is Amlogic proprietary irrelevance that only applies to things running the Amlogic BSP kernel.

Quote from electrolurch

https://paste.libreelec.tv/rowable-skyla.log

Log shows Linux version 7.1.2 (ubuntu@0f3e7d5c77e9) so you are not running the image from my test share which has a Linux 7.2-rc6 or rc7 kernel. The log is not relevant. I have no interest in nightlies; I am trying to develop the next kernel to fix the known-to-have problems kernel in nightlies.

diederik I currently distrust anything from that contributor as a result of conversations over the RK3588 VP9 driver submission. All of their comments complete with inaccuracies were being generated through some AI tool and they bullied the main author into adding them as Co-Developer on the series despite their contributions being little more than minor fixups found through testing, and one "very important fix" patch that was quickly proven to be irrelevant under maintainer review. The patch you've flagged is worded less aggressively than previous things but that's more likely to be evolution in the AI tooling than human influence.