Posts by chewitt

--- 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

SMB clients default connect at SMBv2 and if possible then upgrade the connection to SMBv3 so if you want to test SMBv1 you need to configured min/max SMBv1. Setting min SMBv1 and max SMBv3 results in the same SMBv2 > 3 behaviour. Most hardware will perform best with SMBv3 and my devices are configured identically against a NAS that no longer supports SMBv1 connections. If your 'server' device still supports SMBv1 (might need config forcing to allow it) there's no harm in testing.

RAM size is irrelevant to upstream kernel image as the kernel calculates size so doesn't need to have it forced in the dtb. EMMC size is irrelevant as we do not support installation to internal storage. CPU/GPU opp-points aren't that relevant: You might miss the top end of frequencies but it doesn't make a practical difference. The existing S922X opp-points are enough for software decoded 1080p output and a responsive interface, and reworking the dtb to include higher speeds (I'd guess it's using the same CPU opp-points as the A311D) isn't going to add enough headroom for software decoded 4K media.

Perhaps experiment with SMB client "chunk size" which is now configured/configurable in Kodi SMB client settings. The defaults were changed in Kodi 21 and your setup just might not like them. FWIW, no issues here between an RPi5 and a Synology NAS over Gb LAN using the defaults.

Share the existing OpenVPN service file content.