Posts by chewitt

The LE settings add-on has long history of "if it works, don't fix it" style maintenance because it's all Python code that nobody on current project staff understands; and in that context you'll argue "but it doesn't work" and I'd argue it does for 99.9999% of our users and Dr. Spock's logic quote "the needs of the many outweigh the needs of the few" applies. There's also a general desire to keep interfaces simple and supporting all possible configuration options generally adds complication.

That said, the codebase is all GPLv2 and open-source so there is nothing to stop someone submitting the technical changes that implement the feature you desire. It's just unlikely to be someone on staff as we have learned to avoid that Python juju.

Quote from atirage21

[ 125.938972] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0

This ^ is completely harmless. Ignore.

Spinning rust drives don't last forever. I see around 7-8 years from something in a 24x7x365 NAS in an air-conditioned room (the fringe benefit of living in a hot climate) and never shifts position. Variable temps and going mobile can halve the lifespan. Cross fingers and hope ..

Yes, use a manually configured IP address; don't use DHCP at all.

RPi images intentionally use an LTS kernel (currently Linux 6.18) but the rest of our codebase is now using 7.0+ which includes the reworked in-kernel NTFS drivers; and importantly the fsck.ntfs tools that allow filesystem fixing for most problems to be handled during boot, the same as EXT4. At some point the RPi kernel will bump to a newer LTS that also includes those tools, so in the long-term most of the historic challenges we've seen with NTFS should go away.

I don't see the need to complicate the GUI. If you need to override DNS just use a manually configured address.

Quote from atirage21

2026-07-26 16:44:31.885 T:1760 error <general>: CDVDVideoCodecDRMPRIME::FilterOpen - avfilter_graph_config: Invalid argument (-22)

In code "error" denotes a code path ending. In some cases that it represents a fatal problem. In others it represents nothing more than reaching the end of a branch in some form of logic or decision tree. In this case the content is not interlaced hence opening the deinterlace filter (correctly) errors and playback continues.

Please repeat tests on the current dev image from my test share. I have little interest in current Rockchip nightlies as they use older kernel drivers and ffmpeg, etc.

I've pushed a revised kernel here: https://github.com/chewitt/linux/commits/rockchip-7.2.y which is being used in my current dev branch for RK devices: https://github.com/chewitt/LibreELEC.tv/commits/rockchip - this contains the current patches Kwiboo has been submitting to the mailing lists. I don't have working RK3399 hardware to test with. If you want to eliminate my guesswork you should use this branch https://github.com/Kwiboo/linux-r…803-rk-hdmi-v6/ for the kernel.

Connect the drive to a Windows machine and run chkdsk.exe to check and clear any 'dirty' state from the NTFS filesystem. Linux (in LE11) has no way to do this itself and the drive will not mount (to prevent risk of damage) until the state is clear. NB: If I've guessed correctly the dmesg log should show the problem fairly clearly.

connmanctl config <service_name> --nameservers 8.8.8.8 1.1.1.1

The GUI is probably coded around the concept of mutually exclusive DHCP or Manual connection. See if you can set it from the CLI?

Quote from kelv

Hardware deinterlacing was not working on the 19 Aug nightly

Nice to know but completely irrelevant. I have no interest in current nightlies because they are not running the development kernel that I want tested (and the sole purpose of this thread) which might solve the pile of problems in nightlies.

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.