LE13 nightlies are bumped to Linux 6.15.1 and images in my test share are bumped to Linux 6.16-rc1. No functional changes are expected .. the media drivers are still abandoned.
Posts by chewitt
-
-
I dare say that as Wayland development matures, solutions will be created.
The issue is known about in the Wayland ecosystem for many years already so I woulnd't hold breath or hope of a solution. NB: It's generally not an issue as Kodi GBM works well, although on new hardware where the DRM layer is still maturing there might be some glitches to resolve.
-
Kodi has long supported building with espeak-ng and historically we included it, but the package was disabled in distro options in January 2022 due to some kind of compile issue. There has been no formal espeak-ng release since then, so although there are continuing contributions and commits to the upstream source, the tooling we use to detect updated packages and bump them has not triggered, and espeak-ng support has never been reinstated.
The upstream source switched from autotools to cmake so our package build recipe needs to be reworked, but the latest GitHash can be build with a little fiddling. The perenial challenge is that nobody on staff uses TTS so we can tweak the package to build the binaries but whether we build something usable is always an unknown question.
-
Run "journalctl | paste" and share the URL
-
Have you implemented the general ideas discussed in https://wiki.libreelec.tv/configuration/4k-hdr ?
If yes, and you're using refresh rate changing and whitelist entries correctly, you might need to experiment with the SMB chunk size in SMB client settings. I rather doubt it's network performance though, unless the switch is saturated with traffic or a bad cable/port is causing something to run at half-duplex (but unlikely, else you'd see more general issues).
-
balbes150 is building the image with the Wayland windowing environment, and this restricts you to a single refresh rate because Wayland does not support dynamic refresh rate changes. This is why LE does not use Wayland in official images (only GBM, and Xorg for nVidia). The LE build system supports Wayland because it's used with the Lakka retrogaming fork.
-
Two options for forcing an update to the install:
a) Adding "ssh" to kernel boot params in cmdline.txt wherever PINN stores/places this on the SD card. This will force the device to start the SSH daemon on boot and if you then find the IP address of the device (from the router, or an mDNS app) you can SSH in and wget the latest LE image to /storage/.update then reboot to update.
b) Copying the same update file to the //LIBREELEC/Update SMB share which is enabled by default and maps to /storage/.update and then reboot by cycling power to start the update (not as clean, but will work).
The RPi5 stepping/mesa issue was resolved ages ago so I'm not sure why PINN is offering an older image?
procount, how does PINN get our images?
-
The backup and restore functions in the LE settings add-on are intentionally simple and save/load only to/from a "local" filesystem path; the intention is to support users saving the backup to a USB drive. However Linux is Linux, so if you go and mount a remote filesystem to a local path then it becomes accessible.
"nothing to see here, move along please"
-
I've never used NOOBS or its successor PINN so have no idea what the manual install process is. I'd guess you untar our file and drop the files on the SD card somewhere
-
-
Something have change in the kernel.
LE9 = downstream vendor kernel
LE12 = mainline linux kernel
There is zero kernel code in-common between LE9 images and LE12 images.
-
The existing device-tree file for the C4 only describes HDMI output so changes or an overlay file will be required to describe how that's connected, and then you'll need to apply mixer changes at boot time to set the audio routing.
It's possibly something similar to this for the Odroid HiFi-Shield DAC board: https://github.com/tobetter/linux…ifishield2.dtso
It would be useful to know if the DAC works with any of the distro images that HK creates for the C4. If you can get it working with their kernel in e.g. Armbian then we have some prior art that can be replicated in LE.
-
Your nVidia GPU requires the Generic-Legacy image with X11 windowing. Xorg (X11) does not support HDR. There's nothing we can do about that
-
What DAC chip and driver is used?
-
The only major technical difference in wifi connections between LE12 images and LE11 and earlier is the change from wpa_supplicant to iwd. The change has generated a few minor issues but those are largely resolved, and importantly, none have been related to speed of network association. If you wanted to self-build an image with wpa_supplicant to see if that's the problem difference, this is not that hard (a one-line change in distro build options).
NB: I would expect LE12 to boot slower than LE10 as image sizes have increased and load times got slower with time. I wouldn't expect it to be an overly significant difference though; from my own experience with other RPi boards (albeit much faster ones).
There is an obvious long delay as the network comes up, but that's expected given what you've reported. I don't see anything wrong in the log though. You can run systemd-analyse blame but it'll probably look like https://paste.libreelec.tv/decent-ray.log and again, there's nothing unexpected with network start being one of the longest/slowest elements in boot.
For kicks you can disable BT in config.txt by adding dtoverlay=disable-bt and perhaps unplug the USB Gigabit Ethernet adapter that's connected. That's shaving CPU cycles from boot but unlikely to have any major influence.
-
Put Kodi in debug mode, reboot so the logs are clean, then run "pastekodi" and share the URL when things are up/connected.
-
If you use the default PIA config with the problem CRL certs on LE13 and newer (with new OpenSSL) the problems will exist. If you run LE12 the problem should not exist (as older OpenSSL is used). On LE13 and newer if you remove the problem CRL bits from the default PIA config the problem is worked-around and the config will work. On this topic I think we reached the "You can lead a horse to water, but you can't make it drink" point. The workaround requires 30-seconds' worth of effort. It's up to you though.
On a deeper technical level WireGuard is quite different to OpenVPN but from a high-level user perspective they achieve the same thing and most commercial services support both. If you want to explore that there are setup instructions in the wiki. I'm going to pass on the opportunity to spoon-feed instructions or debate that further though.
-
Code
echo 'options usb-storage quirks=152d:0583:u' > /storage/.config/modprobe.d/usb-storage.conf rebootThere are quite a few reports of "device won't mount" on a range of distros for the "JMS583Gen 2 to PCIe Gen3x2 Bridge" adapter so run that ^ over SSH and see if it mounts correctly now?
