the issue seems to be related to NUC11, different hw, different drivers...
Posts by adam.h.
-
-
I would doubt this issue is LE related - did you try to get any advise on the Intel forum? See this thread as an example.
-
Could you try the provided file on your system? (disable passthrough)
Well, it plays nice both with and without passthrough on my NUC + LE.
Did you try to disable NUC power management as described in these other post threads?
-
-
See here, perhaps it is similar root cause:
-
I wonder why do you need PC+LE for this? RPi4 + DAC + Amp should be enough to have good quality audio.
-
chcore thanks - however that url gives a 403 forbidden error message
It works for me
-
Does it switch to HDR with my LE build?
It does for my Samsung TV, I tried several Atmos/HDR demos and all work very nicely, switching to HDR etc - I remember that was not the case for previous Feb build.
-
Although it is not so bad now. After applaying all these changes described above it hanged only once and I'm unable to repeat it now. So perhaps this was not a driver problem but something related to NUC power management?
I enabled more detailed logs:
Code: advancedsettings.xml<advancedsettings> <loglevel>1</loglevel> <setting id="debug.extralogging">true</setting> <setting id="debug.setextraloglevel">128,2048,32768,262144</setting> </advancedsettings>which generated 200+ MB log file after 2 hours of playing a movie, but perversity of inanimate objects prevented it from more hangs (so far), so nothing really interesting is captured.
-
So I updated NUC BIOS to latest #58 version from Aug 24, 2022 and then also switched Power/Dynamic Power Tech to Off.
And it didn't help, that test MKV still hangs. At least it is consistent (although it is not hanging in the same file position, sometimes it plays 40 min, sometimes 70 min before it hangs).
-
I suppose this is a lot of words just to say that this is unknown problem and sorry, no solution out of the box
Here are two logs with two different hangs on the same MKV: debug and default. Both look somehow truncated, not sure why.
If this is driver issue (as it is my suspicion) you will not find too much in these logs.
The MKV itself is nothing special:
Code
Display MoreGeneral Complete name : E:\The\The.mkv Format : Matroska Format version : Version 4 File size : 5.46 GiB Duration : 1 h 51 min Overall bit rate : 7 026 kb/s Movie name : R22 Encoded date : UTC 2022-08-22 05:21:06 Writing application : mkvmerge v69.0.0 ('Day And Age') 64-bit Writing library : libebml v1.4.2 + libmatroska v1.6.4 Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : [email protected] Format settings : CABAC / 12 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames : 12 frames Codec ID : V_MPEG4/ISO/AVC Duration : 1 h 51 min Bit rate : 6 000 kb/s Width : 960 pixels Height : 720 pixels Display aspect ratio : 4:3 Frame rate mode : Constant Frame rate : 24.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.362 Stream size : 4.67 GiB (85%) Writing library : x264 core 146 -from seleZen Encoding settings : cabac=1 / ref=12 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.01:0.02 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=24 / lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=0 / bitrate=6000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=50000 / vbv_bufsize=62500 / nal_hrd=none / filler=0 / ip_ratio=1.40 / pb_ratio=1.30 / aq=3:0.80 Language : English Default : Yes Forced : No Audio #1 ID : 2 Format : AC-3 Format/Info : Audio Coding 3 Commercial name : Dolby Digital Codec ID : A_AC3 Duration : 1 h 51 min Bit rate mode : Constant Bit rate : 640 kb/s Channel(s) : 6 channels Channel layout : L R C LFE Ls Rs Sampling rate : 48.0 kHz Frame rate : 31.250 FPS (1536 SPF) Compression mode : Lossy Stream size : 510 MiB (9%) Title : English [AC-3 5.1ch at 640 kb/s] Language : English Service kind : Complete Main Default : No Forced : No Text #1 ID : 3 Format : UTF-8 Codec ID : S_TEXT/UTF8 Codec ID/Info : UTF-8 Plain Text Duration : 1 h 43 min Bit rate : 63 b/s Count of elements : 1454 Stream size : 48.2 KiB (0%) Title : Full Language : English Default : No Forced : No Menu 00:00:00.000 : en:Chapter 01 00:00:57.791 : en:Chapter 02 00:15:53.708 : en:Chapter 03 00:26:50.500 : en:Chapter 04 00:38:09.666 : en:Chapter 05 00:46:18.958 : en:Chapter 06 00:59:34.250 : en:Chapter 07 01:08:02.250 : en:Chapter 08 01:13:58.750 : en:Chapter 09 01:19:25.625 : en:Chapter 10 01:27:02.041 : en:Chapter 11 01:33:59.166 : en:Chapter 12 01:44:37.875 : en:Chapter 13 -
So I think it started when I upgraded my NUC to some nightly build in July. Then it still happens with latest smp build from August. I believe it was never happening when I was running previous smp build, which I believe was built somewhere in February?
What happens is that randomly everything is freezing and the sound starts looping in some 0.2 sec cycle producing strange effect. Randomly means that sometimes nothing happens, sometimes it hangs twice or three times over 2 hours movie. When it happens I can only continue after hard reset.
Perhaps this is some driver problem. I tried this fix, but it didn't help. Just wondering if this is happening only to me, or anyone else experienced it?
I'm running now the latest smp build.
-
Updated build in post #1.
So that build I suppose is based on sw dated 2022-08-07. I used previously nightly build as of 2022-08-06 and on NUC 10 it was hanging around every one hour on regular MPEG4/AC3 movies , which was pretty annoing.
This one is not hanging at all (so far), so I wonder what else is different comparing to regular nighties?
-
cool, thanks heitbaum!
-
LE daily builds are not triggered by Kodi development but are triggered by LE commits. It is not obvious for me which Kodi version, kernel version or drivers version has been merged with current LE master branch, thus my question.
-
Updated build (Feb.17):
- Current Kodi master + HDR patches from lrusak
- Linux kernel 5.17-rc4
- Intel media-driver 22.2.1 (fixed HW acceleration on ADL-S)
LibreELEC-Generic.x86_64-11.0-devel-20220217225924-720d9a5.img.gz
So smp, how this build is aligned to current LE-Generic.x86_64-11.0-nightly? Should I expect that all above commits/patches are already in nightly builds or this is not the case?
-
ok, that makes sense - thanks GDPR-7
-
Problem solved in a trivial way, although I'm not following it
So in all my tests I was using HDMI #1 output device as NUC is connected to AVR over HDMI. And I was considering DisplayPort #0 as the USB-C output which I'm not using (see the attached list of recognized devices). But when I switched it to DisplayPort #0 (just in the LE setup), passthrough streaming started working (see attached example Atmos/DTHD input received in the AVR). And this is just setup change in LE, the physical setup is still the same: [NUC]--hdmi--[AVR]--hdmi--[TV].
So now all audio formats are working great in passthrough mode but I don't understand why
Is it a bug or expected feature?
