I figured that the 'constant framerate' is indeed what helps with the stuttering:
So here the setting __I__ prefer for 4k Hevc from BDs:
Intel QS h265 10 bit encoder
constant quality at setting 20
constant framerate and same as source
Encoder preset to quality (vs balanced or speed)
this is rather slow on my machine using a B580 GPU at only 60fps, and reduces the size from 70Gb to 13 Gb with 2 DTS audio streams (non-MA)
So first results trying various encoding options in vidcoder seem to suggest that the 'variable framerate' and or quality too low setting has something to with it. Unfortunately the current version vidcoder (12.xx) crashes when using 'constant framerate'.
I now have 2 versions, one with higher quality with variable framerate where the stuttering is reduced considerably, and one with pure handbrake 1.11 'constant' framerate but higher quality (and pretty slow) that has no stuttering. So it seems this the way to go when confined to using these devices. I don't know about the other arm broadcom baesd devices, but I suspect they aren't that different there.
Normally, in vidcoder, I use constant quality settings around 20 to 22 for BDs and UHD BDs, and also keep the variable framerate setting.
When I'm done, I'll let the forum know the modified settings that I have decided to use.
hmm..
I did some testing of my own with the Salyut7 UHD. The beginning sequence with the cosmonauts floating around the station is almost unwatchable due to stuttering on the rpi5 even when played from local disc (nvme in this case). The same sequence when played on my old NUC 11 plays without stuttering even over the network. But of course the nuc doesn't do audio, so that's
that.
I then had an idea. I took the original 70GB file instead of the 12gb recoded (with handbrake). And lo and behold, no stuttering. So it seems the decoder on the rpi5 has a problem with the recoded stuff, maybe not enough I frames, too long Gops? Is this something that can be adjusted in the decoder?
I'll try the same with some other videos where I saw stuttering (I.e. James Bond No time to die, the beginning car chase sequence)
Other than that, I'll have to see if I have to do something about the recoding (using of course Quicksync, Sw only is way too slow). Any hints welcome.
NUC11’s (Tiger Lake) do not this have this Alder Lake issue. (See thread title)
Set your services cache to ‘recommended’ settings, switch to nfs (from smb). I’ve had no NUC11 audio dropouts here with nfs.
i know, that's why I was wondering. Until recently tiger lake didn't do hd audio at all, and now does no hdmi audio at all on the PAH, so it is a change of some kind. I'll check the services cache for settings, although I don't recall ever doing anything in there. With 'recommended, I guess you mean 'default'?
Switch my NAS to nfs is like buying a new car because the windscreen got dirty (or, for smokers, because the ashtray is full). Not an option because of this.
THX anyway
I tested my nuc11(s) with harry potter BDs (only FHD but some of them have trueHD Audio, the others DTS MA), then star trek kelvin time line, james bond (the last one, forgot the name), and recently Salyut-7 UHD (with dts MA, I think). All of them with audio dropouts for a second or so, starting after 5-10 mins of watching via a wired Gb link from a smb3 share on a nas (the nas is fast enough, believe me).
when I run these on a rPi-5, the audio is OK, but I do get occasional stuttering in panning shots, and some extra weird audio sync issues on really old lo-quality music videos (e.g. from youtube)
So i went for it again.
I have 2 of those.
The nuc11pah, preferred because it has space for sata ssd and CIR, has a min-dp, hdmi and tb port to chose from. The hdmi port is on the right side, and there is no audio at all on that one. I don't have a mini-dp cable right now, so didn't try that, but last time I tried that also didn't work with passthru/HD Audio.
Another nuc11patk has no CIR, a pentium cpu so, I use that for other purposes, has a DP and Hdmi( on the right) . Here in fact hd audio does work initially, but has periodical dropouts after a few minutes on both dolby and dtsMA.
SO no, still no joy with Intel.
It's a pity, since these devices are way more responsive and faster allover, as others have also noted.
/rant
What staff? I thought this OSS? And yes, everything here is a personal opinion, that is a given.
If there were a staff , no one would pay for it. Which is why this consumer/media stuff is being dropped by Intel and MS, see NUCs and Media center.
The intel bugs dating back to 11gen nucs? hd audio used to work but no more, since what, le10? Maybe it's back now? Everytime someone comes up with these old bugs, it always boils down to lacking support from Intel media people and Linux.
Afterall the nucs are HW-wise in a different league than the raspis, fully living room compliant devices with IR, mechanically sturdy and classic design. It really was a pity seeing these go.
I understand the devs fully, e.g. dropping the live-UHD playback issue after a blame-game for a year or so on github. Just admit that it's not worth the time and effort, that is absolutely OK. I'm not spending the time and effort either anymore.
/rant off
That being said, I am just happy and thankful if anyone does pop up with a solution to problems at least on the more supported platforms, as long as they still work, but again, this is OSS, and no one is to blame if it doesn't fit your needs. Use the source, I'd say, but I've done that for now professionally for >45y in different areas, and know how long it takes to get acquainted with a different set of libraries, media stuff being not exactly a small set of specs. So, no, I'm not learning this (in the remaining time I have left 
)
My 11PAhi5 only has one hdmi (on the right) the others are dp and tb. pah because it has native living room compliant IR.
It didn't work last time I checked (ca. 2years ago) and I learnt that Intel is not really supported anymore here, so i gave up.
Let's see what happens, maybe someone could even fix the live UHD tV playback via the tvh client. I'm not holding my breath.
yup, nobody cares, according to kodi forum it's evil Intel's fault.
However, if you start a recording and then watch the recording (with a delay of a sec or 2) instead of switching to channel, that should work. Which is why I think it is a problem of the intel client not handling the rtsp stream properly
it's OK, it was raised long ago and was dismissed as Intel's fault (I disagreed), and I have in the meantime also come to accept the fact that Intel platforms are dying, especially the 11gen NUCs with proper IR (which should have been way better than any arm toys)
.. and now it even seems that this new client can even play some live UHD streams ( not all, though, seems to depend on the actual encoding, i.e.Pro7/rtl uhd on astra doesn't work directly, only whit the usual tricks)
I didn't know that was n option.
Anyway, I went back to 12X released build, where everything was working, and now back to nightly, and lo and behold, everything is still OK.
Nice.
Thanks.
Did I miss something or is the TVH PVR Client vanished from nightly Generic builds?
I'm asking because I noticed that the Guide is not updating for certain channels, and tried to reinstall, but I can't find it anywhere.
Last time i had to do with it was in September 2025, where the WOL wasn't working, but that came back with the build of Sep, 09.
Before that I had asked in the THV 4.2 unsupported thread if this is a server or client issue and was informed, that the client remains supported.
Raspi builds don't have an issue with the guide, so I haven't yet looked if they too are actually gone.
Thanks for any insights
I know, that's why I am asking
how do you wake up your all new and improved amd device, and does it have CEC?
yup, kernel, what I thought.., but then again, what kind of kernel bump would affect this, this is scary, anyway, life goes on...
ohh look, it fixed itself
As of nightly builds of Sep 13:
LibreELEC-Generic.x86_64-13.0-nightly-20250913-d172d73.img.gz
So thx, whoever it was, and out of curiosity, what was it?
