Posts by chewitt

From a coding/development perspective this is a workaround not a fix, but it's interesting. Thanks for sharing.

I have a suspicion the trigger for invalid-key is about signal strength and things on the 'radio' side of WiFi, with the problem being related to how retries are handled. As we know reverting to wpa_supplicant also consistently eliminates the issue; the crack things fall down is probably in iwd, although "it takes two to tango" so interactions between iwd/connman that need examining.

The challenge is/remains: finding people with the code diagnostics skills to triage the issue, who can also replicate the issue.

Quote from rsalvaterra

No time to fill the template

Kodi devs normally auto-close tickets that don't follow the template. They read a ton of tickets, and if users make it complicated to find the important info, they often find other tickets that did follow the template and work on those instead.

Quote from ilmich

the processor may not be able to handle the UI smoothly at such high resolutions

ARM SoC devices need to use 1080p desktop/GUI resolution. You can use 4K for playback as this is hardware accelerated, but the CPUs are nearly all too weak for 4K resolutions.

I've pushed a u-boot 2024.10 bump to images in my test share. It would be nice to hear some test reports with it.

--- a/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi
+++ b/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi
@@ -35,6 +35,13 @@
 	snps,reset-active-low;
 };
 
+&uart_ao_a_pins {
+	mux {
+		/delete-property/ bias-disable;
+		bias-pull-up;
+	};
+};
+
 &usb0 {
 	status = "disabled";
 };

ilovebytes Please test https://chewitt.libreelec.tv/testing/LibreE…droid-c2.img.gz. This bumps the u-boot version to 2024.10 and includes the experimental patch above suggested by MartinB. Any difference?

Quote from Awake

I see no Linux version

That because there is no Linux version - as stated on the downloads page (not currently available) and in the v1.5 release notes.

And? .. how is this related/relevant to LibreELEC?

How is this related/relevant to LibreELEC?

If it's not causing an issue, ignore it.

If the connected TV supports a range of refresh rates, Kodi will switch from the default desktop (1080p@60) to a resolution/refresh matching the media being played to get the best output, e.g. most movies are [email protected]. So a change is normal and generally desirable. However, if you do this on older GPU hardware or with older TVs the switch can be slower and more noticeable. There's a delay option in Kodi settings that allows you to pause output for e.g. 2 seconds to allow the switch to take place. You can also disable that behaviour completely and force all output to the desktop resolution, but then Kodi needs to rework media to match 1080@60, e.g. to make the 520@25fps video content from a PAL broadcast fit into the 1080@60fps output stream. It will do that by resizing and duplicating some frames. Kodi handles this well, but ultimately there are differences and your eyeballs might detect something.

This is not specifically about that topic but might fill in some background: https://wiki.libreelec.tv/configuration/4k-hdr

I don't see anything insightful. Have you experimented with the NFS client caching/chunking options in K21?

I would connect the RPi4 directly to the 'server' PC to isolate the problem. If throughput is better, the slowdown is caused by things you connect between them.

LE defautls to the "ondemand" governor. You can change that with a command in /storage/.config/autostart.sh if needed.

[Unit]
Description=OpenVPN Autorun Service
After=network-online.target nss-lookup.target time-sync.target
Wants=network-online.target nss-lookup.target time-sync.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/openvpn --daemon --config /storage/.config/openvpn.config
ExecStart=/usr/bin/sleep 10

[Install]
WantedBy=multiuser.target

No harm in trying .. ^

I'll need to dig out the box and test. I'm rather time-poor at the moment though so can't promise that happens quickly.

[Unit]
Description=OpenVPN Autorun Service
After=network-online.target nss-lookup.target time-sync.target
Wants=network-online.target nss-lookup.target time-sync.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/openvpn --daemon --config /storage/.config/openvpn.config

[Install]
WantedBy=multiuser.target

See how that ^ works?

Quote from yamcenutzer

I don't believe LE will ever come out of it's "raspi is the only system we really work for " niche

These days LE runs on a wider range of hardware than ever before, but the level of support we receive from upstream maintainers on Intel hardware and most ARM SoC platforms isn't equal to the support that we see from the RPi developers. Project staff are frequently asked for recommendations. Do we suggest something we know has a few glitches and glacial support (Intel) or relies completely on community development (Allwinner, Amlogic, Rockchip). Or do we suggest an RPi board with few issues to report in the first place, and anything we do flag is normally fixed under 24 hours by Engineers super-keen to help and get it resolved. Our influence on the userbase is minor though. Recent modern NUC devices and derivatives are good, but not as-good as the devices that NUC reputations were built upon in the past, and users talk to their friends and relatives and the easiest-to-use and reliable devices are the ones that are purchased most.

GPU (rendering) has nothing to do with media decoding .. so not relevant for LE/AMLGX