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.
Posts by chewitt
-
-
LE defautls to the "ondemand" governor. You can change that with a command in /storage/.config/autostart.sh if needed.
-
Code
Display More[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.targetNo 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.
-
Code
Display More[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.targetSee how that ^ works?
-
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.
-
AFAICT the only difference between AM6 and AM6+ is the plus using a DV licensed SoC chip (S922X-J) which is irrelevant for upstream kernel using devices. If it makes you feel better, rename "meson-g12b-ugoos-am6.dtb" to "meson-g12b-ugoos-am6-plus.dtb" and pretend that you have a special dtb for your board.
-
What I am after is a few lines of code that will make the add-on wait for the VPN tunnel to be up.
You cannot delay the add-on inside Kodi, but you can use a systemd service to schedule the VPN to start after the network is up and before Kodi, so the tunnel is established before Kodi autostarts the PM4K addon.
Have a look at /storage/.config/system.d/wireguard.service.sample and tweak that to suit whatever VPN technology you're using, e.g. if using OpenVPN not WireGuard, substitue an openvpn command instead of the connmanctl connect command. NB: If using OpenVPN you should really investigate using WireGuard instead as it'll significantly increase tunnel throughput on the same point-to-point connection.
-
The RPi5 works fine when directly connected to the TV, but once you add the AVR in the chain things don't work. That firmly points fingers at the AVR, but the usual methods of negating that or forcing output also appear to disagree with the AVR.
Please delete /storage/.config/firmware/edid/edid-HDMI-A-1.bin and then run "getedid create" again with the AVR inline between RPi5 and TV. It won't solve anything but I'd like you to upload/share the .bin file that's created here so we can have one of the RPi developers have a look at it - they collect problem files for testing.
popcornmix any ideas?
-
The non-trivial suggestion is to self-build an image that uses wpa_supplicant instead of iwd to see if that's the issue. The switch to iwd has overall been successful, but over time there's been a few users whose setups are tripping over edge cases and/or borderline reception and iwd doesn't seem to perform as well in those situations as older wpa_supplicant. We aren't going to be moving back to wpa but we've intentionally left support in the build system for a while to support people doing some a/b testing.
-
Use "pastekodi" and then we see the corresponding system log at the same time.
-
Remove the edid override with "getedid delete" and add "video=HDMI-A-1:1920x1080M@60" to boot params in cmdline.txt; this forces the HDMI-A-1 output to 1080p@60 which sometimes helps if the kernel can't quite decide on what to use.
-
You need to use an LE12 nightly which contains some updates specicially for RPi5 2GB which was realeased annoyingly shortly after LE 12.0.1 was made available. Update and it should work fine.
