Posts by chewitt

It's not possible to configure multiple resolutions, but it shouldn't be necessary. Configure for 720p and Kodi should simply scale the older 480p media to 720p for output. The default behaviour for 4:3 content will be (or should be) to show vertical black bars left/right of the video. The alternative is to stretch media to 16:9 of use a zoom, but that usually sucks. You can experiment with options via the OSD menu once video is playing.

This was merged an hour before you posted: https://github.com/LibreELEC/LibreELEC.tv/pull/9376

The forum sees a moderate amount of attempted pharma spam from human 'bots' that bypass whatever technological registration/login restrictions are implemented. It's occasionally annoying, but the list is effective and overall impact is low so it stays.

Moving back on-topic: There's an air of mystery around the trigger conditions, but ultimately the probably-radio-side cause is less important than ensuring retries (or resets, or doing something like that) result in a connection. It needs someone to run iwd and connman in debug mode and then trace what's observed in logs (both are reasonably verbose and somewhat human readable) against the actual code, and spot where the code/logic breaks. I too script. I can pseudo-read code to a point, but not well enough for this issue. It's not just about reading logs through. It probably requires some patching to add "printf" reporting of values that are being moved around between services.

Quote from Cissou

I think it's impossible to update python to 3.x in this LE version ?

Correct, because the embedded version of Kodi used requires Python 2.x to function, and if you bump beyond that version of Kodi towards the Python 3.x era you'll find that support for proprietary decoding methods (amcodec) has been exorcised from Kodi.

AMLGX on WP2 is usable but not perfect (and no internal tuners of course). I've not abandoned all hope that someone will revive work on the upstream hardware decoders to improve things, but i'm not hold breath. And I doubt anyone will ever get the internal tuners working. The technical gap between fixing up driver code enough to compile (which I already did) and rewiring it to modern kernel frameworks (which is way beyond my abilities) probably isn't too huge, but it takes a certain level of knowledge, persistence, and desire to wade through some horrible driver code, that doesn't come along often.

Have you run "rpi-eeprom-config --edit" ?? .. You need to append BOOT_ORDER=0xf416 to the device to have it boot from NVME.

Thanks for the feedback (and credit for the change is for MartinB not myself). The next challenge is to explain why this issue appears now (recently) and not years ago. In other words: what other change has someone done in the (u-boot/kernel) codebase to result in this being required?. Once that's been explained the upstream maintainers can think about pushing a global change to e.g. gxbb/gxl platform .dtsi files (not board level files) to fix the issue everywhere.

In the short term I'll include the patch for C2 and see if it also solves a similar (but older) issue report on WeTek Hub.

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?