There are experimental images (not in LE master branch) for AW, while AFAIK it doesn't work for RK. Both, AW and RK, platforms needs HDMI and I2S driver improvements in order to make it work. HDMI driver is common between these two, but I2S driver is not.
Note that AW experimental images are reportedly broken - I have to update them and re-test.
By HD audio you mean passthrough?
No, just put it in /storage/.update and reboot - it will be updated during next boot.
Now here is no image corruption, but the images freezes. Stop and play channel solves it.
How often freeze happens? Same amount as image corruptions before?
The second time I had frozen not only image but the whole Kodi that had self rebooted after a while.
Please enable debug logs in options and when crash happens, upload crashlog(s) from /storage/.kodi/temp and provide link
levitsky86 -=guybrush=- Please test this update: LibreELEC-H3.arm-10.0-devel-20210425125640-5701db2-h264-fix.tar
I think you should not see corruption anymore.
Better don't compare it to Rockchip, Amlogic or Allwinner - they needed 4+ years and are partly not even there yet
I tend to disagree (except about AML part) 
AW and RK support deinterlacing while RPi does not. RK is also almost on pair regarding HDR. In short, each platform has features that are not necessarily implemented on others. But I agree that RPi development progresses much faster.
I did exactly as the Official guide says, but the TrueHD and DTS-HD are not working at all.
High bandwith PT won't work - at least two drivers need to be extended and ALSA config must be changed accordingly. I created hackish experimental implementation for Allwinner, but I don't have knowledge about Rockchip internals to do the same for RK.
offbeat Thanks for detailed analysis. Enabling performance governor on H6 is not a good idea because H6 generates a lot of heat even on lower frequencies (many are not happy with that). You can of course enable it locally.
There is a reason why Allwinner port is marked as "stable beta" in LE10 release announcements. There is plenty of corner cases which needs to be fixed, but I'm actually quiet happy that it works as well as it does. Decoding using request API in ffmpeg is known to be suboptimal. We didn't rewrite it just yet, because kernel will in near future receive some uAPI updates which would allow even more efficient decoding. As mentioned before, GPU frequency switching doesn't work on H6 for some unknown reason, which nobody can figure out. However, maybe default frequency can be raised same way it is done for A64 (via DT)? This would be acceptable until dynamic switching is figured out.
Note that I don't know for any peripheral which would rely on CPU clock directly. You can always check how clocks are related and configured in /sys/kernel/debug/clk/clk_summary. VPU, DRAM and GPU have their own, dedicated PLLs, which makes them independent from rest of the system.
P.S. Testing it was a pain, the way ffmpeg is packaged in LibreElec is sooo confusing, binary programs aren't included in base build at all and ffmpeg-tools addon uses completely different build options, without any hardware decoding patches...
I actually use separate distro (Arch for ARM) when developing ffmpeg/Cedrus or other, mostly display related features. I apply all relevant LE patches to kernel and then netboot it. This allows much quicker turnaround time. However, I test Kodi only with LE.
I have one more question. I see there are settings for buttons repeat time in CEC adaptor. Should they be set to the corresponding brand's TV remote model, or not? I am just trying to figure out why I have problems with CEC on my old Pioneer Kuro plasma TV. I've got multiple CEC100 errors when CEC adaptor (in Kodi) and HDMI control (in TV) are enabled (see the attachment).
It's first time I see this kind of error. But then again, CEC behaves differently on different devices. I have experience only with my LG B8 TV, where CEC behaves normal. Just experiment...
offbeat Reason why OSD helps is probably because EGL provides vsync... I don't know. Maybe windowing/gbm: Add display clock by popcornmix · Pull Request #19601 · xbmc/xbmc · GitHub will help. IDK.
First of all, there is a BIG difference between my scenario and his. I'm not talking about iptv so connection bandwidth isn't an issue for sure. I'm talking about DVB-T broadcasted contents.
That difference is not really important. Check test image I posted and see if dmesg is flooded with same type of lines levitsky86 reported. If it is, stream gets corrupted and decoder for some reason can't cope with such corrupted stream.
Do I need to open the box to physically see the components or can it be done without disassembling? I have ssh access in both.
Opening the box is the easiest way. dmesg output from Android would probably tell what storage is used.
yeah, it might be issue with pastebin service.
No, it's Armbian, so this should go to their forums and board Orange Pi Zero is not supported here (too little RAM).
Fortunately, I also have OrangePi 3 I tested with fresh installation and overlays work. Try to flash latest nightly image to spare card and see if it changes anything.
For reference, my extlinux.conf:
LABEL LibreELEC
LINUX /KERNEL
FDT /sun50i-h6-orangepi-3.dtb
FDTOVERLAYS /overlays/sun50i-h6-i2c0.dtbo /overlays/sun50i-h6-i2c2.dtbo
APPEND boot=UUID=2204-3027 disk=UUID=c1742531-5dac-434c-8390-f1decb06f821 quiet console=ttyS0,115200 console=tty1NOTE: Your UUIDs will be different.
If that doesn't work, then I have no idea.
Correct, nightly releases still follow LE10, which uses 5.10
Can you please specify in what sense isn't correct?
I have no clue, but it obviously doesn't work.
I wrote two overlays for I2C0 and I2C2 like so http://ix.io/2WSc (and same for I2C2). Then I included them to extlinux.conf like so FDTOVERLAYS /overlays/sun50i-h6-i2c0.dtbo /overlays/sun50i-h6-i2c2.dtbo. Now I have:
LibreELEC:~ # i2cdetect -l
i2c-3 i2c DesignWare HDMI I2C adapter
i2c-1 i2c mv64xxx_i2c adapter I2C adapter
i2c-2 i2c mv64xxx_i2c adapter I2C adapter
i2c-0 i2c mv64xxx_i2c adapter I2C adapterNote - this is on PineH64 model B, but I don't see any reason why it wouldn't work on OPi3.
Binary version of overlays: Index of /overlays/
well, there you have it - overlay you're using isn't correct - it shouldn't freeze during boot and you should get additional i2c bus listed. What is wrong with it - I don't know. From what I can see, seems good.
There is no other i2c port on the GPIO header
All three are there, just pins are named differently. I2C1 is on SPI1-MOSI and SPI1-MISO, I2C2 is on UART3-RX and UART3-TX and they lack pull ups, so yeah, you most probably use I2C0.
BTW, 0x36 is PMIC address. You are probing wrong bus. Make sure you have now 3 buses and probe all except HDMI.
Is it right ?
It is (maybe just move FTDOVERLAYS one line higher, although it shouldn't matter).
What's next ?
Are you sure your device is connected to I2C0? H6 has 3 I2C buses, 4 if you count one for PMIC. If you sure, then I don't know...
You have to add line FDTOVERLAYS /overlays/sun50i-h6-i2c0.dtbo to extlinux.conf. I'm a bit lazy regarding documentation...