Vontar x96 (s905x / RTL8723BS BT/WiFi )
working fine with gxl_p212_2g_slowemmc.dtb (BT/WiFi/Ethernet/CEC - all OK)
but with gxl_p212_2g.dtb have problem: first start with toothstick is OK but next after reboot have dark green screen and bootloop. If again start with toothstick - will OK but then after reboot green screen and bootloop again.
PS: On stable/night build I use gxl_p212_2g.dtb without any problem with reboot.
Not sure if this is specific to the GXL builds but I noticed that in 4K 50/60Hz modes it auto switch to 4:2:0 10-bit rather than 4:2:2. My TV can do 4:2:2 10/12-bit @4K 50/60.
The spec is 444 for 4K 24/30 and 420 for 4K 50/60.
The spec for 4K 50/60 is 4:2:0 10-bit and 4:2:0/4:2:2 12-bit. Why not use 4:2:2 12-bit?
There’s no benefit in 12bit or 4:2:2 for video playback except some potentially higher bandwidth requirements.
If you really want, you can force 4:2:2, although it would apply to all 4K refresh rates, including the lower ones.
Is this behavior hardcoded by amlogic? If not - can you point me in the right direction where exactly in the source code can this be tweaked?
And I don’t agree that there is no benefit. Although the source video is always 4:2:0 - we’d still want to deliver it to the display with as low losses as possible.
This has been how it is from the early days of the 4.9 kernel.
You can dig through the linux-amlogic repo for cdu13a’s commits.
The main reason for using the default 4:2:0 is compatibility, where 4:2:2, unfortunately, isn’t close to being as compatible. In addition to that, people will more likely face issues when 4:2.2 12bit is being used with a cheap (bad) HDMI cable.
Read this topic to get more info about this
Thanks, but that has nothing to do with HDMI output modes.
I’m getting an occasional Ethernet lockups on Le Potato, something similar to this. Happens during file transfer over LAN and sometimes during live tv streaming. No idea how to reliably reproduce, seems random.
Agree, but explains the main use for 4:2:2 and why it’s not used and supported on any Kodi platform.
Thanks, I will see if I can manage to reproduce this.
2 posts were split to a new topic: Possilbe patches to improve kodi
I encountered another, really bizarre issue. This time I can easily reproduce it.
A fast navigation in Kodi’s GUI makes my USB DVB tuner to completely lock up. The tuner will require a power cycle. The issue can be easily reproduced when scrolling the TV channel list really fast. I made a video of this. The tuner fails at 00:40.
The issue occur only when the output is set to 4K 50/60Hz. I can’t reproduce it with 1080p.
Does this only happen with the the Funhouse(or any other build based on the amlogic-ng-on-gxl branch) or does it happen with the current stable as well?
I didn’t test it with the current stable. I can test tomorrow if it can help with debugging this.
Scratch that, it also happens with 1080p. It looks like heavy GPU activity somehow interfere with the USB traffic and the tuner craps out.
I tried to change I/O scheduler from default noop to cfq and deadline but that didn’t make any difference.
CoreELEC funhouse_2024.6 - Release Notes
Changes since funhouse_2011.6:
• Update CoreELEC funhouse build to match CoreELEC 9.2.3 release
• Fix dtb for LePotato (The LePotato image should now work properly with 1gb model)
• Several minor fixes and improvements
• Internal DVB support is still missing.
• Booting from sd card causes a delay in booting the device.
• There are probably numerous other like unfinished and odd things.