dropouts when watching hd tv (1 Viewer)

[RicoHTPC]

Hello,

I am having problems in getting smooth playback with hd tv.
When I watch hd tv (720i or higher) the picture and/or the sounds stops randomly for a blink of an eye.
I guess it is to syncronize picture and sound again if I interpret the logs right.
When using the mpar (which I did at these logs) a lag between picture and sound may also develope.
Without mpar there's no lag but more dropouts.
The respective periode of time begins around 21:00 in the logs as I switched to a hd channel.
I watched this channel until leaving mp around 22:18.

Hope someone can point me anything that might help.

 

[Owlsroost]

What sort of network do you use ?

Yes, the 'pauses' in TsReader.log are because it is running low on data, but it's not happening very often and I think it's because the display refresh rate is slightly faster than 50 Hz.

When I watch hd tv (720i or higher) the picture and/or the sounds stops randomly for a blink of an eye

How often do you see these random picture or sound 'stops' ?

 

[RicoHTPC]

The amount of stops differs. From every two minutes to every ten minutes (everything subjective of course).
And when the picture/sound lag starts is hard to say because the very first beginning of this lag may seem normal at first
and it starts seamlessly anyway.
How could I get my display to run at no more than 50hz?
And I use a 1gbit wired network.

 

[Owlsroost]

A couple of things to try (they both basically do the same thing):

1. When you start TV (or change channels), pause it for a second or two - this will build up a buffer of live TV, so it should be a longer time before the 'stops' begin.

2. You can force TsReader to buffer more data automatically by changing this registry setting:

HKEY_CURRENT_USER\Software\Team MediaPortal\TsReader, set "BufferingDelayInMilliSeconds" to a (decimal) value in milliseconds (range is 0 to 2000, default is 0). Note - this will add delay to live TV channel changes since it needs to build up the buffer before play starts.

 

[RicoHTPC]

Thanks for your suggestions, I'm interested if they will change anything.
Unfortunately I can't do this before tuesday next week because I'm out of town.
But generally these seem to be workarounds instead of tackling the problem at the source.
What's the real cause behind this?

 

[Owlsroost]

Assuming we have found the correct problem, the real cause is that the PC is playing the live TV stream slightly faster than the broadcaster is sending it, so after a while MP runs out of data and has to pause playback to allow the broadcast stream to 'catch up'.

Digital TV sets, set top boxes etc. adjust their local playback clock to match the stream (so they don't have this problem) but PC's can't do this.

Some time ago I did a lot of work to allow MPAR to be used by TsReader to adjust the playback speed (to work around the problem), but I stopped development eventually because MPAR still had some random A/V sync issues, so I had to give up using it for live TV (on my HTPC). I've experimented with a few other ideas to workaround the problem, but nothing has really worked properly/reliably.

 

[RicoHTPC]

because MPAR still had some random A/V sync issues

So do I.
With mpar I've got sync problems (or dropouts to catch uo with the sound) and randomly muted sound after switching channels.
Without mpar I've got even more dropouts but no sync problems.
Do we know to what part of the hardware setup these problems are related?
Will changing the graphic card do any good?

 

[HTPCSourcer]

2. You can force TsReader to buffer more data automatically by changing this registry setting:

That's really interesting. Is there any means to determine the discrepancy between actual PC clock and theoretical speed? Also, I am a little bit uncertain how a fixed buffer can cure such difference. Whatever you define for the buffer will be eventually eaten up, and a hick-up will occur. It should reduce the amount of stuttering though, as synchronization starts a new cycle, correct?

Adding 100-200ms is probably not an issue. The additional delay in channel changes does not make a big difference to the current 2-3 seconds.

With respect to the issue itself, my feeling is that it was better in the past, although I am not able to quantify this in terms of which version was better.

Regards,
HTPC_Sourcer

 

[Owlsroost]

2. You can force TsReader to buffer more data automatically by changing this registry setting:

That's really interesting. Is there any means to determine the discrepancy between actual PC clock and theoretical speed? Also, I am a little bit uncertain how a fixed buffer can cure such difference. Whatever you define for the buffer will be eventually eaten up, and a hick-up will occur. It should reduce the amount of stuttering though, as synchronization starts a new cycle, correct?

Correct - increasing the initial buffering just increases the time before TsReader has to pause the stream - it helps but it isn't a cure. The 'pauses' do not perform a full re-sync to the stream - that only happens when you start play, skip forward/backward or fast-forward/rewind.

With respect to the issue itself, my feeling is that it was better in the past, although I am not able to quantify this in terms of which version was better.

The logic was changed (some time ago) because users complained that it sometimes paused when it didn't really need to, so it was de-sensitized a little (and had some other changes).

 

[RicoHTPC]

But again: what can I do to really get rid of this problem?
I mean obviously it's not that many people who have this problem.
Would changing the graphic card help? Is ATI known for this problem?