TV repeatedly freezing momentarily (2 Viewers)

[doveman]

MediaPortal Version: 1.2.3

Description
I get a lot of freezing whilst watching TV, where the picture will just stop momentarily. I think it affects the sound as well, it's just not always obvious if no-one's talking at the time it happens.

Someone has analysed an xperf capture for me and tells me this:
"I can see the high CPU usage spikes by mediaPortal and the ISR/DPC. I can see that the amdppm.sys driver with the function C1Halt causes it. This is the power management driver for your AMD Athlon™ II X4 630 Processor. This call causes halmacpi.dll!HalpClockInterruptPn CPU usage. This repeats very 100s. The MediaPortal changes the CPU affinity (kernel32.dll!SetThreadAffinityMask) and this seems to cause the spikes."

I tried changing to the High Performance power setting to prevent the CPU changing frequency (with it on Balanced apparently "it only goes to 1,6GHz (2nd Cool'n'Quiet state)"), but it seems the capture looks much the same and I still have the same problems with TV freezing.

I tested with Ch4 and BBC1 (logs attached) to confirm it doesn't just affect one channel.

Steps to Reproduce:
Watch Live TV.

EDIT: Just to clarify, this is on my "Spare HTPC" system, which is all I'm using at the moment as I test it for my brother.

 

[tourettes]

MediaPortal Version: 1.2.3

Description
I get a lot of freezing whilst watching TV, where the picture will just stop momentarily. I think it affects the sound as well, it's just not always obvious if no-one's talking at the time it happens.

Someone has analysed an xperf capture for me and tells me this:
"I can see the high CPU usage spikes by mediaPortal and the ISR/DPC. I can see that the amdppm.sys driver with the function C1Halt causes it. This is the power management driver for your AMD Athlon™ II X4 630 Processor. This call causes halmacpi.dll!HalpClockInterruptPn CPU usage. This repeats very 100s. The MediaPortal changes the CPU affinity (kernel32.dll!SetThreadAffinityMask) and this seems to cause the spikes."

EVR presenter calls SetThreadAffinityMask() to workaround some buggy bios / HW -> http://msdn.microsoft.com/en-us/library/ms644904(VS.85).aspx. In any case it is perfectly valid to call that method, if it triggers some issue then there must be some underlying issue with the HW (or most likely drivers).

ISR/DPC <-- those are both kernel level stuff. ISR == interrupt service routine, DPC == deferred procedure call. Both are something that MediaPortal (or any other user mode program) cannot difrectly trigger.

After 1.3.0 alpha is out (and you have updated to it) I can build a dshowhelper. dll without that one specific call for testing. The side effect is that it would probably break lot of older systems that are currently working ok (we don't have any clue what HW Microsoft is talking about). It will require quite big amount of testing to be able to remove that workaround from the code - it will affect the video frame scheduling accuracy.

In any case I would say that there is some driver level issue on the system where you see the ISR/DPC spikes.

 

[doveman]

Thanks tourettes, I'll see if there's any drivers I can disable then, to test if that fixes the problem.

I'll be happy to help test the dshowhelper.dll once 1.3.0 alpha is out.

 

[tourettes]

I'll be happy to help test the dshowhelper.dll once 1.3.0 alpha is out.

Just remember to remind me - I'm 101% sure that I will forget to build the .dll.

 

[doveman]

Just remember to remind me - I'm 101% sure that I will forget to build the .dll.

Sure will do, once everything's settled down a bit after the 1.3.0 Alpha release

 

[doveman]

Hi tourettes,

Just wanted to feed back what the person who's been looking at my xperf traces for me has said:

The MediaPortal may hang becasue it waits. I can see it causes ntkrpamp.exe!KiProcessThreadWaitList calls which calls ntkrpamp.exe!KiReadyThread.

So we must capture ReadyThread data, too.

xperf -on latency+POWER+DISPATCHER -stackwalk profile+CSwitch+ReadyThread -buffersize 1024 -MaxFile 256 -FileMode Circular && timeout -1 && xperf -d DPC_Interrupt.etl

But I must say I never used xperf to analyze hangs. I've uses the Builin profiler of Visual Studio 2010 which uses xperf/ETW in background and shiows me nice list.

I then found that disabling the four VMware Player services (VMWare Authorisation Service, VMWare DHCP Service, VMWare NAT Service, VMWare USB Arbitration Service) substantially reduced the frequency of hangs, although when they do occur they're still just as bad. This was after upgrading to 1.3A, so that may have helped a bit too.

Then I made a trace with the above command and after that was checked I was told:

DPCs should be no issue.

MediaPortal uses Timers which do some .Net Remoting (SOAP) calls (System.Runtime.Serialization.Formatters.Soap.dll!?) which seems to block the tool. I think such a coding issue causes the hangs.

This is all over my head really but I expect it makes sense to you

Anyway, whenever you've got time to build that dshowhelper.dll (if you still think it might help) I'll be happy to test it

 

[doveman]

I should just clarify that (I think) whenever TV hangs, there's continuity errors in the tv.log, so I'm not sure if this means the modded dshowhelper.dll won't help. Perhaps if that's causing hiccups, they could be affecting the tvserver though, thus resulting in the continuity errors?

 

[mm1352000]

tv.log or TsWriter.log?

 

[doveman]

tv.log or TsWriter.log?

Yeah, sorry it's TsWriter.log of course (and mirrored in TsReader.log).

I've attached the logs from 1.3A so you can see how they compare to the previous ones (apart from the errors in error.log (mostly ARC-related) and tvserver_error.log).

 

[mm1352000]

I should just clarify that (I think) whenever TV hangs, there's continuity errors in the tv.log, so I'm not sure if this means the modded dshowhelper.dll won't help. Perhaps if that's causing hiccups, they could be affecting the tvserver though, thus resulting in the continuity errors?

Unless it is loading the HDD, I can't think of any way that dshowhelper would do that. As I think I've explained before, continuity errors in the TsWriter log are usually caused by:
1. Signal issues (which can be caused by things like tuner overheating and interference as well as regular low quality signal from the cable).
2. HDD load.

Have you tried running the resource monitor and checking what the HDD utilisation is like when the problems occur? I know that I can get freezes and corruption when other HDDs spin up and down.