Posts by yamcenutzer

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.

Quote from HomerJau

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

c'est la vie

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?

No disrespect, but until i find a way to send only specific logs around the faulty component/timeframe that's not gonna happen. The logs contain too much stuff that's none of anyone's business and also beyond my internet quota.

In this specific case I am guessing that logging the timespan around enabling of a previously configured (with the ip and mac address to wol to) hts-client would suffice.

I've already come to live with the fact that the Intel Platform is doomed to die in the media community rather sooner than later so I can live one more bug/regression.

i can however of course show you the fact that was logged in KODI.log:

successful case:
...

AddOnLog: pvr.hts: starting PVR client
2025-05-24 19:38:40.355 T:1066 info <general>: WakeOnLan - Magic packet send to '18:C0:4D:28:FC:F6'
2025-05-24 19:38:40.356 T:1005 info <general>: PVR Manager: Starting
2025-05-24 19:38:40.357 T:1067 info <general>:

...

unsuccessful case:

Creating PVR client: addonId=pvr.hts, instanceId=1, clientId=2025648334
2025-09-10 22:09:27.042 T:938 info <pvr.hts>: starting PVR client
2025-09-10 22:09:27.043 T:909 info <general>: initialize done
2025-09-10 22:09:27.043 T:909 info <general>: Running the application...
2025-09-10 22:09:27.043 T:948 info <general>: WakeOnLan - Magic packet send to '18:C0:4D:28:FC:F6'
2025-09-10 22:09:27.045 T:909 info <general>: starting zeroconf publishing
2025-09-10 22:09:27.045 T:909 info <general>: starting upnp client
2025-09-10 22:09:27.046 T:909 info <general>: starting upnp renderer
2025-09-10 22:09:27.047 T:956 info <general>: ES: Starting UDP Event server on port 9777
2025-09-10 22:09:27.047 T:956 info <general>: UDP: Listening on port 9777 (ipv6 : true)
2025-09-10 22:09:27.087 T:909 error <general>: JSONRPC Server: Failed to connect to sdpd
2025-09-10 22:09:27.087 T:909 info <general>: JSONRPC Server: Successfully initialized
2025-09-10 22:09:27.088 T:909 info <CWebserver[8080]>: Started
2025-09-10 22:09:27.088 T:909 info <general>: AIRPLAY: Cleaning up photoassetcache
2025-09-10 22:09:27.089 T:909 info <general>: AIRPLAY Server: Successfully initialized
2025-09-10 22:09:27.089 T:909 info <general>: CWSDiscoveryListenerUDP::Start - Started
2025-09-10 22:09:27.090 T:938 info <general>: PVR Manager: Starting
2025-09-10 22:09:27.199 T:947 error <general>: InputStream: Error opening, D:/bdrips/mkvtoolnix-64-bit-89.0/mkvtoolnix/data/sounds/finished-2.webm
2025-09-10 22:09:27.484 T:930 info <general>: WakeOnAccess [mediaserver] triggered by accessing : smb://mediaserver/shares/tv-serien/folder.jpg
2025-09-10 22:09:27.485 T:930 info <general>: WakeOnAccess success exit, server already running
... bla bla...

2025-09-10 22:09:29.761 T:944 info <general>: SETTINGS: __init__ # updateThread Started
2025-09-10 22:09:29.764 T:944 info <general>: SETTINGS: set_auto_update # manual
2025-09-10 22:09:29.794 T:1041 info <general>: SETTINGS: run # Waiting
2025-09-10 22:09:30.091 T:948 error <pvr.hts>: unable to connect to tvserver:9982
2025-09-10 22:09:30.592 T:948 info <general>: WakeOnLan - Magic packet send to '18:C0:4D:28:FC:F6'
2025-09-10 22:09:33.638 T:948 error <pvr.hts>: unable to connect to tvserver:9982
2025-09-10 22:09:34.138 T:948 info <general>: WakeOnLan - Magic packet send to '18:C0:4D:28:FC:F6'
2025-09-10 22:09:37.184 T:948 error <pvr.hts>: unable to connect to tvserver:9982
2025-09-10 22:09:37.685 T:948 info <general>: WakeOnLan - Magic packet send to '18:C0:4D:28:FC:F6'
2025-09-10 22:09:40.731 T:948 error <pvr.hts>: unable to connect to tvserver:9982
2025-09-10 22:09:41.231 T:948 info <general>: WakeOnLan - Magic packet send to '18:C0:4D:28:FC:F6'
2025-09-10 22:09:44.278 T:948 error <pvr.hts>: unable to connect to tvserver:9982
2025-09-10 22:09:44.778 T:948 info <general>: WakeOnLan - Magic packet send to '18:C0:4D:28:FC:F6'
2025-09-10 22:09:44.782 T:1102 info <pvr.hts>: Received permissions:
2025-09-10 22:09:44.782 T:1102 info <pvr.hts>: