The log snippet looks OK to me. Only 2 channels are used for PCM, even if you have 8 audio output channels enabled in the settings.
Read here about the difference between passthrough and non-passthrough: Click!
Try passthrough with only 2 audio output channels. As mentioned, multiple channels will be encoded into 2 (FL, FR), so you'll get all 6 DTS channels with only 2 audio output channels in the settings.
OK, then I think the missing data formats (post #14) are the issue. I already had an internal team discussion about this. Unfortunately nobody has the skills to fix it. So you can only wait for updates. 
LE is not a conventional Linux distro, so /var/lib/alsa exists inside the read-only SYSTEM file and there is no asound.state file there because it is not required (sound is configured on each boot). There is also no need to create alsa.conf files since PCM and PT work fine with the default board based conf that we embed in the image (the "error" message that you post shows "Found hardware: gx-sound-card" which proves this is loaded). All GXBB devices have the same alsa.conf and this is proven with a large number of box/board devices, and C2 is the most-used device with the AMLGX image. I have no idea what the issue is, but I'm highly confident it's local to your iLE nstall or more people would be complaining (and it works fine here). Have you gone through the normal routine of checking cables, ports?
I know what LE works, and after experiences with OSMC I think it's pretty good idea.
If problem is local to me, then only thing I haven't checked is situation where system check what is connected to HDMI and configures sound device to use TV capabilities (don't know if that's even possible). Well, maybe I have to disconnect Odroid C2 from TV and reboot it. Cables, ports, TV and speakers are good, beause it worked well with Raspberry Pi and OSMC (where eg. Boblight doesn't work - on Odroid C2 and LibreELEC Boblight works fine). Problem with software (or drivers) is shown by speaker-test (only two channels detected).
Here is an output from Raspberry Pi (well, this one is not connected to any TV):
rexus@blueberry:~ $ speaker-test -c 6
speaker-test 1.2.4
Playback device is default
Stream parameters are 48000Hz, S16_LE, 6 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 480 to 10922
Period size range from 480 to 10920
Using max buffer size 10920
Periods = 4
was set period_size = 2184
was set buffer_size = 10920
0 - Front Left
4 - Center
1 - Front Right
3 - Rear Right
2 - Rear Left
5 - LFEAll channels are detected (I should connect it to something to check if it really works).
Why more people don't complain? I don't know, but how many of them are using 5.1 sound configuration (stereo runs out of the box)? More, how many of them can hear the diffrence between passthrough sound and stereo streched to 5.1 by speakers (what my speakers is doing by now and it sounds... well, not bad, but it's definitely not DTS 5.1)? Maybe I'm the first one who wants clear sound on this board 
How many audio output channels are selected on LE's settings?
What's the HDMI version number of your HDMI cables? You should try 4K cables.
I've tried 5.1 and 2.0 with same result. At this moment it is 5.1.
Thanks. The test with 2.0 output channels was important to me.
Why bother about cables and receivers (which work with another source), when system don't even try to output 5.1?
We don't know that. HDMI negotiation is first, selecting a codec for the resulting connection is second.
This is the current also conf we embed: https://github.com/chewitt/alsa-l…sound-card.conf
This is an older version: https://github.com/chewitt/alsa-l…sound-card.conf
The older conf has all the analogue device pcm extras needed for speaker-test to work with multiple channels. In the absence of all of them (as per the current conf) speaker-test will only output stereo since this is all the default pcm device supports/exposes. This is 100% same on my system; which happily outputs multi-channel PCM and PT on the HDMI connection (which is not the analogue pcm device). So kudos for playing "spot the difference" .. but this difference is not the thing you are looking for.
NB: The only reason the older conf exists was an earlier attempt to work around a driver not-technically-a-bug where alsa does not pass mixer controls correctly. This patch hacks a fix: https://github.com/chewitt/linux/…702a070dc71c133
I'd ask that you play with cables and AVR/TV ports. Multi-channel output depends on the ELD data read from EDID/HDMI and the usual "but it works in the legacy image!" claim means little due to a) the upstream codebase being 100% different, and b) the amount of hideous stuff the legacy kernel ignores/overrides/fakes to work around TVs and monitors that provide bad/broken EDID data.
And yes the greatest percentage of AMLGX users are probably using default 2-channel output. However, enough folks have complained about the earlier multi-channel state (that the kernel patch resolved) that I know people are using multi-channel output.
Multi-channel output depends on the ELD data read from EDID/HDMI and the usual "but it works in the legacy image!" claim means little due to a) the upstream codebase being 100% different, and b) the amount of hideous stuff the legacy kernel ignores/overrides/fakes to work around TVs and monitors that provide bad/broken EDID data.
Probably this is the problem - drivers on Odroid can't "talk" to my TV - either because bad data from TV or some bugs within them.
For another test I've installed last LibreELEC on Raspberry Pi 3 and again - it worked out of the box. Log (for comparison) is here. So - drivers on Raspberry Pi recognize (or do some workaround?) my TV properly. What was surprise to me - boblight is working too (not worked on OSMC), but only with DRM PRIME disabled (what disables hardware decoding too 
).
Maybe I sould stay on Raspberry Pi 3... or give a try with Raspberry Pi 4. More testing needed 
I'm still thinking it's an LE bug, as mentioned in post #14.
Because nobody else cares, try to compile your own LE, and fix that bug. We have basic instructions here: Click!
2023-08-30 18:37:01.357 T:910 info <general>: ffmpeg[0x3cb1230]: Stream #0:1(por): Audio: ac3, 48000 Hz, stereo, fltp, 384 kb/s (forced)
2023-08-30 18:37:01.357 T:910 info <general>: ffmpeg[0x3cb1230]: Stream #0:2(eng): Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 1536 kb/s (default)^ Have you selected the right audio stream? .. it looks like the Portugese audio is stereo, and English is 5.1.
Code2023-08-30 18:37:01.357 T:910 info <general>: ffmpeg[0x3cb1230]: Stream #0:1(por): Audio: ac3, 48000 Hz, stereo, fltp, 384 kb/s (forced) 2023-08-30 18:37:01.357 T:910 info <general>: ffmpeg[0x3cb1230]: Stream #0:2(eng): Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 1536 kb/s (default)^ Have you selected the right audio stream? .. it looks like the Portugese audio is stereo, and English is 5.1.
Use the gear icon on the playback bar to check it.
Wow, that would be extreme shame 
I've selected right stream. But after checking it once again (who knows - sometime complex problems has very easy solutions) I've found that stereo AC3 tracks work in passthrough mode. Not changing much.
If you're using official LE11 images (release or nightlies) please update to https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.3.tar and see if that makes a change?
Nothing changed in sound playing - "crack" then no data when passthough enabled, stereo when disabled.
Your version has broken my GPIO script started from autostart.sh (power on speakers when TV is on etc.), so I've turned back to official one.
Can you please go back to chewitt build, activate debug logging, replicate the issue, and post a link to the log?
I'm curious whether the missing data formats are available on that build: