01_KODI https://textbin.net/xvgmyfv8iq
02_System https://textbin.net/gtdeqtbz9a
LE 11 (nightly-20220319-5591832) and trying playback of a file with DTS-HD master audio:
01_KODI https://textbin.net/caxeljrf9q
02_System https://textbin.net/cvsjujpeqo
Go to "Passthrough output device" setting and switch to the correct port.
Unfortunately, not as easy as that. Passthrough generally speaking works, just not for the audio formats I mentioned.
I have selected the passthrough output device where the Denon amplifier is shown as connected (ALSA: HDA Intel PCH, DON DENON-AVR on DisplayPort #0) and enabled passthrough of all the listed formats. (AC3, E-AC3, DTS, TrueHD, DTS-HD). Dolby Digital and DTS passthrough works just fine. Passthrough of TrueHD and DTS-HD does not. If I press the "Info" button on the Denon remote during playback of TrueHD or DTS-HD the signal is shown as "Unknown".
I'm guessing the reason for the amplifier being listed as connected to "DisplayPort #0" is the protocol conversion. The block diagram for NUC11PAHi5 shows HDMI 2.0b -> PCON -> DP1.4 -> Tiger Lake UP3 (1135G7 with Iris Xe).
Then there's the problem with AAC 5.1 which isn't related to passthrough. If I play content with AAC 2.0 the Denon identifies it as 2-channel PCM and I get sound. Playback of content with AAC 5.1 results in "Signal: Unknown" and no sound.
Doing the same tests with my old NUC (with a gen 3 i3 CPU) everything works as expected. Passthrough of TrueHD/DTS-HD works and AAC 5.1 is received as 5.1-channel PCM. Same version of LE (10.0.1) in both NUCs, same settings, everything downstream from the NUCs is the same.
I recently bought a NUC11PAHi5 to replace my old gen 3 NUC. I installed LE 10.0.1 and configured the new device to exactly match the settings I have on the old NUC (also LE 10.0.1). The NUC is connected to a Denon AVC-X3700H via HDMI. I did some tests using a few Dolby and DTS trailers with various audio formats. To my surprise the files with Dolby TrueHD, Dolby Atmos, DTS-HD Master and DTS:X produced no sound at all. I also discovered that files with AAC 5.1 didn't produce any sound either. After a failed test I couldn't get any sound at all from the NUC11, even with files that had worked previously, until after a reboot.
My old gen 3 NUC has no problems at all with passthrough of the above mentioned HD audio formats. The amplifier receives and identifies all the signals correctly. AAC 5.1 also works - the amplifier identifies the signal as 5.1 channel PCM. I literally just pull the HDMI cable from the NUC11 and connect it to the old NUC and it works... I have compared the settings with a diff tool to be sure I'm not missing anything and they are the same.
I have updated the NUC11 with the latest (0043) BIOS from Intel and also updated LE to 10.0.2. I even tried a recent LE 11 nightly build. Still no joy... I then installed Windows 10 and Kodi 19.4 on a second drive. Annoyingly that works (using WSAPI) and I get sound from the HD audio files as well as the files with AAC 5.1. I'd rather not resort to using Windows though...
So it seems to me that the NUC11PAHi5 and LE 10/11 don't play well together. Is this a known problem? Are there any solutions or work-arounds I can try? (BTW. The NUC11PAHi5 is one of those NUCs with HDMI -> PCON -> DP1.4 if that matters.)
I see you are referring to the OP's first post here. Perhaps you were doing that in your previous post as well? I just assumed that you were replying to my (the latest) post... 
Anyway, I can subscribe to the "phone home" theory. It would be interesting to capture and analyze the traffic, i.e. see what happens when you browse to a NFS share (mapped with IP) via Kodi's GUI... Unfortunately, I'm not in a position to do that right now. Obviously my router couldn't forward any DNS queries when it had lost its Internet connection, so if a DNS lookup was made it would explain why Kodi couldn't connect to the share. There's still no valid reason for making a DNS lookup just to connect to a local share via its IP address, but who knows...
I'm thinking it is a dns/dhcp issue. is your nas dynamic or static addressed? and are you using just the gateway as your sole router on your network?
The NAS has a static IP address and is located on the same subnet as the NUC with LibreELEC. Both are connected via cable to the same switch which is plugged into one of my router's LAN ports. I used the static IP address for the NAS when I mapped the shares via Kodi's GUI. I can't see any valid reason for either DNS or DHCP being involved here and mounting the shares manually from the LibreELEC command line (while Internet was still down) worked fine. That being said, I suppose it could still be a DNS issue if browsing to a share via Kodi's GUI triggers a DNS lookup for some reason. Why it would need to do that to connect to a local share (using IP, not name) I don't know. I have the same shares mapped on a number of other systems in the house and they all worked perfectly fine. It was only trying to access the shares via the Kodi GUI that failed.
I don't know if this is at all relevant to the thread or helpful in anyway, but... I have 9.97.1 generic on my Intel NUC and have had no problems with NFS whatsoever. It's a very basic installation with no add-ons. I have added a couple of NFS shares hosted on my QNAP NAS as sources via the Kodi GUI. (Using the QNAP's IP address.) This has worked flawlessly up until yesterday when I suddenly lost Internet connectivity. With Internet gone, Kodi could no longer connect to the QNAP shares. Other computers on my local network had no problems connecting to the QNAP shares. I logged in to the NUC/LibreELEC via SSH and tried mounting the QNAP shares manually from the command line and that worked without any problems. It was only accessing the shares via Kodi's GUI (Videos -> Files -> <share>) that failed. When Internet connectivity was restored, it was again possible to browse the shares via the GUI. I have no idea why loss of Internet connectivity would affect accessing NFS shares on a LAN using IPs and only via the GUI, but there you are. Unfortunately I didn't have time to create any debug logs before Internet connectivity was restored and I really don't want to experiment with disconnecting my WAN.
