Posts by chewitt

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.

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.

Quote from sh33p0mat

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.

Kodi only supports upgrades not downgrades and I've never seen tools/scripts for downgrading. The sole option* is to update the LE12 DB so it finds new media and manually mark a few things read to align statuses. I'd also drop the newer DB version tables from the DB (if using a shared SQL DB) or delete the newer local DB files (if using local DB files) so that in the future when you update to LE13 again, Kodi migrates the current LE12 files instead of using outdated LE13 files.

* unless you're a database wizzard, but those people don't normally post here for help.

Just find the dtech thread which has links to his 9.2.8 image, download it to /storage/.update, and reboot. The only option newer is AMLGX (LE 12.0.1) which will boot from SD card but requires you to invoke recovery boot (toothpick boot method) to force u-boot into reading boot scripts and loading the right files. You can revert back to Android by removing the SD card. You can revert back to SD booting older LE images if you repeat the toothpick boot method.

Quote from primuspaul

So basically if I want to watch YouTube, I must download it with a regular computer and save to my NAS to watch on LibreELEC?

The Kodi repo has two YouTube add-ons (YouTube and Tubed). These days both require some "jumping through hoops" to register for personal Google API keys, but it's a one-time hassle. I said 'no' to SmartTube because there's no add-on blocking in either of them - what you see depends on your geo.

Connect the RPi5 direct to the TV and then run "getedid create" to capture the EDID data on the HDMI connection to file and then (re)configure boot files to use this and ignore the EDID data from the AVR. Then power down and reconnect to the AVR. Now if you power up .. things are working?

Nope.