Could you before doing this, please update to a Nexus nightly at least? TrueHD has seen many, many fixes since January - and yeah - there was some stuff with the Packer not correct, so please first things first. A nightly is also fine.
Version: Starting Kodi (20.0 (20.0.0) Git:20230115
Edit: Simplest: Backup your .kodi directory and shortly upgrade to kodi's nightly ppa - thx.
Thanks both, really appreciating your input and thoughts here. I actually tried a nightly already before without success. I did it again now to provide some log information:
Debug log from nightly
I would also try some new hardware but the availbility of suitable mainboards for my purpose is simply not given at the moment.
Can you please first try if the issue goes away if you run it at 1920x1080 at 24p? Only?
It does indeed go away with 1920x1080@24p
chances would be even less than very unlikely if using high end hdmi cables....
(sorry i just had to chirp in, ive had some total crap hdmi cables)
With the new kernel I first thought the issue was gone, but then I had much more severe audio drops, which sometimes even the AVR recognised by signalling an input/decoding loss. Bottom line: does by far not happen so often anymore but a lot more intense. Still nothing in the log.
(2023-03-01, 23:02)fritsch Wrote: [ -> ]I don't want to talk about HDMI cables 
- cause chances are very unlikely ...
haha, we are on page 2 of the thread and it is the first time we discussing HDMI cables. I think that's good
I would also have said: very unlikely as 60p works, but I am not in the details and it is worth a try although I do not think I have a bad cable.
You could try LibreELEC from a USB stick as a groundtruth comparison. While I don't think it's a bandwidth issue (60p works), it seems that you can influence it with the changed kernel. Problem with such random tip kernel upgrades is: random different stuff might happen, the good or the worse - just like you see it now. It might be worth to open a kernel bug with the intel people and providing them all possible logs with drm.debug=0xe enabled. At the end, it might be small details of the way the HEAD is configured in 24p vs. 60 hz mode. HDMI under the hood might use 12 bpc for the one and something else for the other ... -> maybe your AVR remote's info button already shows a data format change here. Just an example: It might be that in 24p mode the HDMI uses RGB888 or YUV444 with 8 bit while in 60p under the hood a yuv 422 12 bit output happens. Both things the kernel can decide and do like it wants.
Or more simple things like: Audio-Clock 192 khz / 8 channels / 16 bit not stable in 24p mode. From the effects kernel can play multiple roles here.
But try LibreELEC from USB stick first. It uses a newer kernel from a tested environment. Also does not matter if you use the newest LE or something older. Your J4105 for sure worked at a point with 24p.
@
Flachzange On the debug screen there is an info called "a/v corrections". Do the values change after audio drop outs? (maybe some seconfs after the drop ots occured)
EDIT: there might be a couple of drop outs need to see a/v corrections.
(2023-03-01, 18:19)fritsch Wrote: [ -> ]I thought about that as well - but as it works perfectly fine in 60 hz ... I don't think that this is an issue. A/V clock adjusts we would see, when discon happens. And as audio clock and video clock are separate but only synced via PTS to each other, I would not assume that suddenly audio runs dry in 24 hz mode, while it does not in 60 hz. But yeah - just assumptions.
Movement of audio packets from one stage to another is much smoother on 60hz. On 24hz the driver might suck in very large chunks at once, which might leed to an empty queue at a stage.
IMO it is very unlikely that the driver adds or drops packets silently.
(2023-03-02, 05:20)fritsch Wrote: [ -> ]maybe your AVR remote's info button already shows a data format change here. Just an example: It might be that in 24p mode the HDMI uses RGB888 or YUV444 with 8 bit while in 60p under the hood a yuv 422 12 bit output happens. Both things the kernel can decide and do like it wants.
AVR and TV always show RGB 12 Bit. Not matter what I have tested so far.
(2023-03-02, 05:20)fritsch Wrote: [ -> ]But try LibreELEC from USB stick first. It uses a newer kernel from a tested environment. Also does not matter if you use the newest LE or something older. Your J4105 for sure worked at a point with 24p.
Same issue.
(2023-03-02, 10:12)FernetMenta Wrote: [ -> ]@Flachzange On the debug screen there is an info called "a/v corrections". Do the values change after audio drop outs? (maybe some seconfs after the drop ots occured)
0 a/v corrections
Why is it working properly if I go to the TV first and send the audio back to the AVR via eARC (Btw. same cable.)? Wouldn't this give us an indication where to look for the root cause?
0 a/v corrections = not kodi
what about settings on the denon as this user states -
https://forum.kodi.tv/showthread.php?tid...pid3143322
Quote:it was as simple to set setting on my Denon in following place Setup / Video / 4K/8K Signal Format and change the format from "Enhanced" to "Standard".
(2023-03-02, 22:06)jepsizofye Wrote: [ -> ]0 a/v corrections = not kodi
what about settings on the denon as this user states - https://forum.kodi.tv/showthread.php?tid...pid3143322
Quote:it was as simple to set setting on my Denon in following place Setup / Video / 4K/8K Signal Format and change the format from "Enhanced" to "Standard".
Which I did and it works (see first post), but it is only a workaround.
Edit: But fair point. It seems I have missed that thread during my research.
Edit2: And fun fact: The user took the advice from this thread and it also means new Intel hardware will not solve it
(2023-03-02, 22:08)Flachzange Wrote: [ -> ] (2023-03-02, 22:06)jepsizofye Wrote: [ -> ]0 a/v corrections = not kodi
what about settings on the denon as this user states - https://forum.kodi.tv/showthread.php?tid...pid3143322
Quote:it was as simple to set setting on my Denon in following place Setup / Video / 4K/8K Signal Format and change the format from "Enhanced" to "Standard".
Which I did and it works (see first post), but it is only a workaround.
Edit: But fair point. It seems I have missed that thread during my research.
Edit2: And fun fact: The user took the advice from this thread and it also means new Intel hardware will not solve it
yep sure does say that, i went back and read some of it but tldr... anyway, best of luck