powerarmour An obvious question: Is this media something you ripped, or is it "test media" that you downloaded from the Internet? .. because 9/10 "test" files are designed to stress/break decoders to find bugs. TL/DR; use real media not test media.
vaughng Allwinner H6 does not support hardware AV1 decoding so ffmpeg will fall back to software decode, and as AV1 is mostly used on large sized 4K media/streams the CPU will choke on the task.
It looks like the soundbar capabilities aren't being exposed to the RPi5 through EDID data on the HDMI connection. The debug log clearly shows only FL/FR speakers are available; hence Kodi is downmixing 6.0 media to 2.0 to match the advertised layout. If pass-through is used, the stream is not decoded (for downmix) and magic on the TV side results in the soundbar working.
I'd be looking into TV settings for eARC? options to ensure the Soundbar EDID is presented to the RPi5, then things should work. If nothing exists the workaround might be to temporarily connect the RPi5 directly to the soundbar, run "edid create" to capture the EDID data, then reconnect the RPi5 to the TV again. On reboot the RPi5 will see the cached Soundbar data not the live TV data.
The Kodi package is updated several times between those two releases; the before/after tags/githashes are:
-PKG_VERSION="20.2-Nexus"
-PKG_SHA256="4e81abf81172812bc8891f69a7a80a2b846298cecaae7b5009725e28a3040c23"
+PKG_VERSION="1497cc889e52558258739405bca536167f626cc2"
+PKG_SHA256="38ea7898c088bd266426dd7e545a92cac5307d94a2406258232c60e73297f7d3"Compare the contents of guisettings.xml under the two different skins and see if there are differences.
These days you can probably handle ext4 things under WSL, but NTFS dates from '90's era MS which was more aggressively against the idea of allowing use of anything other than the one true OS to rule them all..
Start with sharing a Kodi debug log with several plays that demonstrate the scenarios (with an explanation).
powerarmour read and implement a mode whitelist: https://wiki.libreelec.tv/configuration/4k-hdr .. then share a clean log.
The source Da Flex linked is outdated and won't compile for the Linux 6.6 kernels we use in LE12. This one is more up-to-date and should be fine: https://github.com/lwfinger/rtl8852bu. It's not something we will entertain adding to the main LE image, as we have a long-running policy of refusing to add more Realtek vendor drivers.
In Estuary:
Home > Add-ons > My Add-ons > navigate left so the view controls and filters are visible > Check for updates
I've watched some GoT episodes yesterday where I downloaded subs from OpenSubtitles and the line order was indeed bottom-up not top-down (so I can confirm a problem exists). However there were also episodes where subs were either already downloaded or perhaps embedded (not sure which, it was late) where the line ordering was displayed correctly, so it's not the case that all subs are bad and more testing is needed to narrow the problem. I'm travelilng for a few days now so can't easily check, but if you could do more testing to ping things down it would be helpful.
On restart binary add-ons like Tvheadend are binary incompatible and will be marked bad (until they update). If you have an issue with the repo .. force refresh it.
Original credit to Kwiboo who spotted the original problem and authored the patch.
But after restoring the backup, the same probleme appears.
Once you restore the LE11 (arm) backup on LE12 (aarch64) the restored binary add-ons aren't going to work as they are compiled for the wrong CPU architecture. This should eventually resolve itself when the LE11 add-ons self-update to compatible LE12 versions. In this scenario all you needed to do was update to LE12 and let add-ons udpate themselves, the clean install ahieved nothing.
I'll ask for a Kodi debug log, but I have a hunch that will reveal you're using some IPTV source with thousands of channels, which will mean it's a pirate source, and then we don't care about the problem. In the unlikely event I'm wrong .. provide the log.
is there a good guide on how to convert it?
There's probably something in Google if you look, but realistically there are only two options:
a) Move data off the disk, change the filesystem type, move the data back.
b) Shrink the NTFS partition, create an EXT4, start to shuttle the data from one to the other and progressively shrink one, expand the other, until all the data is moved, then delete the NTFS partition and expand EXT4 to 100%.
Both will be rather slow .. depending on how full the disk(s) are.
NB: No idea if there's an actual conversion routine. I wouldn't normally trust that kind of thing.
I suggested "video=HDMI-A-1:1280x720M@60" and not "video=HDMI-A-1:1360x768M@60" for a reason 
In the past exFAT and NTFS required "userspace" drivers that suffered from slow read/write performance. These days both of those filesystem types have native kernel drivers so performance isn't an issue. However both have reliability issues and NTFS notably can have issues that can only be corrected using chkdsk.exe on Windows. As such, the preferred format for Linux drives in LE is still ext4.
