Posts by yamcenutzer

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>:

BTW, I don't think this actually a client issue, since nothing much has changed there. I now tend to think that this might have to do with eth drivers/kernel settings.

Any one any ideas?

like I said, builds back from Aug 25 continue to issue wols.-

Generic nightly builds after 2025-08-25-288f19b : this build is the last one where waking a configured external tvHeadend server is successfully awakend vial WOL.

Builds after that cannot do that any more.

Tested with 2 NUC11 with different Eth chips (Realtek vs Intel)

Raspi-4 builds still do successful WOL to the server, so seems only a intel hw issue.

obviously that was the first thing to test...

anyway, I really find it difficult to find a time after work hours, when the tv is not already in use...:-) I guess it'll have to wait till the weekend...

Also , a remote raspi4 still has an older nightly which still probably works

ok, so this is client bug then, which is still supported, I guess, I'll collect info and report as bug when I got the time

Thx

Is this about the server or the client (or both)? I'm asking because as of last week the client does not wake up an external server any more using the wake on lan feature

BTW, the (first) github issue above https://github.com/xbmc/xbmc/issues/23699 has been dropped so no one cares anymore

Yes it is a known issue mentioned from different sources (see above). and the workarounds are:

a. use http (and lose time shift)

b. with tv-headend you can start a recording and watch from the recording buffer. dunno if that is an option on your service

Something different:

does your n100 do hd Audio Passthrough (DTS-MA HD, TrueHD, Atmos?, anything else?)

Quote from maple

....

I thought LibreELEC was supposed to be software that anyone can use, even if you know absolutely nothing about Linux. Sorry to have bothered you.

grow up dude. This is OSS, a pure hobby project.

I am a software dev myself, but not in this area.
E.g. for this particular problem you'll not only need someone who knows the code in question, AND has access to a tvheadend pointed to a source sending UHD. You also need this someone to have this kind of hobby to spend his time with. That is not all too common, it seems.

For Intel issues in general, I have come to believe that support for OSS media projects is dimishing.

HEVC live playback from tvheadend on intel platforms is also a problem on Libreelec.

Libreelec however doesn't crash, it just doesn't play the video.

The problem is a combination of the tvheadend live stream and Hevc via VAAPI.

The workarounds on LE: record the program and watch the recording (quasi live with a delay of a 2-2s), or switch to using http protocol and lose time shift.

It's been reported long ago and being worked on e.g. here: Disney+ Addon not playing properly the stream when VAAPI is enabled · Issue #25383 · xbmc/xbmc