MrMC

just to be clear, it everyone that still has issues. pvr server is remote or local ?

That is the case for me at least. My server is remote, but apparently HoIger is have the same issue with a local server connection (100 Mbit?).

mrmc.log with debug enabled -> [email protected]. please just don't send the log and expect us to figure out your setup/problem. describe it in detail, that helps us quickly jump to the right sections and try and see what is going on.

I wanted to make sure that it is not my network causing issues so I did some tests with the OS X builds from kodi.tv. MacBook connected to the same network via Wi-Fi.

Results:
v16.0 = no issues
v16.1 RC2 = no issues
latest nightly build of v17.0 = same issues as with MrMC 2.x. TV stream gets buffered for some time, plays for a few seconds then buffers again.

This doesn't look like an issue of MrMC 2.x to me. If I remember correctly the PVR part is a back port from Krypton, right? If so, it looks like Openelec (used as the server) including Kodi v16.x has an issue with Krypton Clients. Or maybe it's just Tvheadend? But I doubt that, as the problem also exists with the latest beta of Openelec that ships with HTS Tvheadend v4.0.9 which looks pretty recent.

I think HoIger is on to something.
I did a quick test with my setup, and I got the exact same result:
16.0 = No issue
16.1 = No issue
17.0 = Same issue as MRMC 2.x

Thanks hronas for testing and confirming! I just sent out my MrMC log file via mail. Let's hope there's something useful in there, which could help to find a fix for MrMC. I'm not really fond of updating the Openelec backend to a nightly build of Kodi v17.0.

Ok... I couldn't resist and updated the Openelec backend to todays version of the Krypton test build. Bad news: This version serves the Kodi v16.x clients without issues, but the buffering issue with Kodi v17 and MrMC 2.x still remains.

So it's not a compatibility issue.

Right. It's not compatability, but perhaps something in the 17.0 pvr client/player, which is brought into mrmc 2.x?

Think I found it, audio except for passthrough should be treated as float, two channel. Just fixed an issue with acc, two channel getting passed as the same thing.

The telltail is this in the log. You should only see this if passthrough is enabled and the audio format is ac3 or dts.

NOTICE: bool CAAudioUnitSink::setupAudio() setup audio format: [lpcm] Mixable Interleaved 2 Channel 16-bit Signed Integer LE (48000Hz)

came across that hint with passthrough being buggy while crawling the internet for a solution already. Problem is: ATV is connected directly to the TV. Therefore passthrough isn't enabled. But YES. I think that part is where we should dig deeper... The channel used to create the log uses AC3 but passthrough *defintively* was not enabled. Neither in the global settings nor per channel.