Posts by yamcenutzer

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

Yup, done that been there, the cables are ok, they work elsewhere.

And I have tried 4 different certified for HDMI xyz 1000k UUUHD and good for world peace cables...

So I somehow keep suspecting the TV...

until I get fed up one day and stop obsessing, or it starts working for no reason again.

BTW, why did you single out that one warning line about waiting for a buffer? What does that tell you?

hastebin - wikisuyafe

Ok here's a debug log of me try to play the atmos and another truehd file, which in both cases were detected correctly on the TV, but NOT passed on the AVR.

Followed by 2 test files with various DTS MA, which were passed on the AVR.

Again, I don't think it's kodi/libereelc. I think the TV and/or the AVR are acting weird. I was hoping to find someone here who has a similar setup :

Panasoniv TV <-> eARC Denon AVR

and maybe confirm/deny that dolby passthrough via eARC works

Thx anyway

Quote from smp

There are better ways to make those boxes work with IR remotes. FLIRC USB is the most obvious one.

No, for me, just ugly addons. Compare to clean NUCs with proven Ir capability incl. Power on/off with the ancient but still undefeated MC remote functionality.

Quote from smp

You mean this? Your NUC11PA does not have a native HDMI, as can be seen on that block diagram. You simply bought the wrong hardware.

As for the 11gen nucs, yes that never got fixed after it used to work as far way back as the nuc5. But then the change to the all new and improved graphics subsystem a few years ago, and we lost (on Intel) hd audio passthrough, multiple hdmi outputs (for everybody) . The LSPCON problem was supposed to have been 'resolved' years ago, according to the wiki. But that was to optimistic, it seems.

Quote from smp

The only non-working live tv stream I have ever encountered is a HotBird 4K HLG test channel. I actually try to find a solution for that. It appear to be a bug in Kodi's VAAPI code.

I am seeing this on Astra 19.2 on the UHD channels of Pro7/Sat1, RTL, SES-UHD-Demo and some others . And also on the Hotbird UHD Demo channel. My setup here is a remote tvheadend server, maybe a local one behaves differently, I don't know. I see on github, that activity has taken up, thats's good, as you can already reproduce the problem. When I did a ts capture and tried to playback, it actually worked, so I thought it was essentially the same as a 'recording'.

I kind of gave up on Intel, since I understand that their Boxes are/were pricey compared to a raspi, and Intel's support for OSS, especially when it comes to media, is rapidly deteriorating. The new N100 boxes seemed to be a way to go, esp. the ASUS one actually has IR, but who knows how long that would last, and I still haven't heard any confirmation that HD audio passthrough works there. The live UHD issue is a minor inconvenience compared to that.

Thanks anyway.

It's not a Libreelec problem, since hd audio is being passed through to the TV (it shows ATmos/TrueHD on info). But It either doesn't pass on to the AVR, or the AVR doesn't 'like' what it sees on eARC. It seems to get the individual channels pre-decoded. But again only Dolby. DTS get's passed through properly.

Dolby(AC3/ThrueHD/Atmos) is also passed correctly if I connect the raspi to the AVR directly rather than via eARCfrom the TV.

I am asking here, because I believe

a) there are people with a similar setup, and Panasonic TV are knowen to be flaky and require a real wall-power off from time to time (done that, of course)

b) I strongly believe it was working just a week or 2 ago.

I'm still curious about these things, they have no own IR, no CEC and , being Intel, they have been essentially abandoned by the community with all really ancient bugs, no HD auidio passthrough, no uhd via live tv

What is the intended use case for these then?

Hi,

Am I hallucinating or did some recent firmware updates (as in the last 1-2 weeks) to either PanaSonic TV or Denon AVR prevent TrueHd , Atmos or any Dolby audio being passed down to the AVR?

I am kind of sure this was working in my setup not too long ago.

My setup is: raspi5 via HDMI to Panasonic Tv, via eArc enabled hdmi to Denon AVR.

DTS HD MA gets passed through, just not anything Dolby (not even normal AC3).

The TV shows that the incoming stream has TrueHd or Atmos, but seems to not pass it on. The AVR just shows some weird 'Multi'

I didn't change anything on the raspi, but I remebered that both the TV and the AVR are connected to the internet with auto updates. Normally they notify me, but who knows...

Anyone any ideas?

Thx.

IIRC it also works if you start recording the program and then switch to the channel being recorded and then choose to watch the recording even with almost no delay.

So maybe offline with a file might also work. That might have to do with the fact that recordings are in different format than live.

so noone has any ideas? create a new thread?