LiveTV freezes and shows a lot of artifacts (1 Viewer)

[Owlsroost]

What does that mean? What is the cause for this?

I can't tell you that from the logs, but the trouble actually starts slightly earlier at 09:44:37.974 (from evr.log) :

12-09-2013 09:36:32.670 [1984]Present first sample - end
12-09-2013 09:44:37.974 [1984]Dropping frame, nextSampleTime -21.31 ms, last sleep 1.50 ms, last pres -51.00 ms, paint 2.86 ms, queue count 4, SOP 176, EOP 338, RawFRRatio 1, dropped 1, drawn 24229
12-09-2013 09:44:37.979 [1984]Dropping frame, nextSampleTime -6.27 ms, last sleep 3.10 ms, last pres -56.00 ms, paint 2.86 ms, queue count 4, SOP 176, EOP 338, RawFRRatio 1, dropped 2, drawn 24229
12-09-2013 09:44:38.029 [1984]Dropping frame, nextSampleTime -16.23 ms, last sleep 0.00 ms, last pres -47.00 ms, paint 2.89 ms, queue count 3, SOP 272, EOP 435, RawFRRatio 1, dropped 3, drawn 24230
12-09-2013 09:44:38.040 [1984]Dropping frame, nextSampleTime -7.22 ms, last sleep 2.60 ms, last pres -58.00 ms, paint 2.89 ms, queue count 4, SOP 272, EOP 435, RawFRRatio 1, dropped 4, drawn 24230
12-09-2013 09:44:38.293 [1984]Dropping frame, nextSampleTime -20.84 ms, last sleep 2.09 ms, last pres -50.00 ms, paint 3.00 ms, queue count 4, SOP 176, EOP 346, RawFRRatio 1, dropped 5, drawn 24241
12-09-2013 09:44:38.299 [1984]Dropping frame, nextSampleTime -6.86 ms, last sleep 3.58 ms, last pres -56.00 ms, paint 3.00 ms, queue count 4, SOP 176, EOP 346, RawFRRatio 1, dropped 6, drawn 24241
12-09-2013 09:44:39.323 [1984]Dropping frame, nextSampleTime -869.48 ms, last sleep 1.09 ms, last pres -900.00 ms, paint 5.10 ms, queue count 4, SOP 176, EOP 464, RawFRRatio 1, dropped 7, drawn 24248
12-09-2013 09:44:39.323 [1ee8]Scheduling sample from the past (774.33 ms, last call to NotifyWorker: 0.39 ms, Queue: 4)
12-09-2013 09:44:39.325 [1984]Dropping frame, nextSampleTime -851.21 ms, last sleep 1.09 ms, last pres -901.00 ms, paint 5.10 ms, queue count 3, SOP 176, EOP 464, RawFRRatio 1, dropped 8, drawn 24248
12-09-2013 09:44:39.325 [1ee8]Scheduling sample from the past (755.96 ms, last call to NotifyWorker: 0.29 ms, Queue: 3)
12-09-2013 09:44:39.327 [1984]Dropping frame, nextSampleTime -833.21 ms, last sleep 1.09 ms, last pres -903.00 ms, paint 5.10 ms, queue count 2, SOP 176, EOP 464, RawFRRatio 1, dropped 9, drawn 24248
12-09-2013 09:44:39.327 [1ee8]Scheduling sample from the past (738.32 ms, last call to NotifyWorker: 0.33 ms, Queue: 2)
12-09-2013 09:44:39.329 [1984]Dropping frame, nextSampleTime -815.50 ms, last sleep 1.09 ms, last pres -905.00 ms, paint 5.10 ms, queue count 1, SOP 176, EOP 464, RawFRRatio 1, dropped 10, drawn 24248
12-09-2013 09:44:39.329 [1ee8]Scheduling sample from the past (720.20 ms, last call to NotifyWorker: 0.24 ms, Queue: 1)
12-09-2013 09:44:39.332 [1984]Dropping frame, nextSampleTime -798.72 ms, last sleep 1.09 ms, last pres -908.00 ms, paint 5.10 ms, queue count 0, SOP 176, EOP 464, RawFRRatio 1, dropped 11, drawn 24248
12-09-2013 09:44:39.332 [1ee8]Scheduling sample from the past (703.55 ms, last call to NotifyWorker: 0.31 ms, Queue: 0)
12-09-2013 09:44:39.334 [1ee8]Scheduling sample from the past (685.45 ms, last call to NotifyWorker: 2.22 ms, Queue: 0)

...the "Dropping frame, nextSampleTime -869.48 ms, last sleep 1.09 ms, last pres -900.00 ms" means that it hasn't rendered (presented) any video frames to the screen for 900ms, which is probably because something has blocked it for 900ms - which could be MP, the OS, video drivers, some other driver hogging the system etc etc.

All the dropped frames/late samples afterwards are because the queued up video frames are now late (relative to the render clock), so they have to be discarded to maintain A/V sync, It almost manages to do this, but it gets hit by another stall of 990ms :

12-09-2013 09:44:42.293 [1984]Dropping frame, nextSampleTime -960.67 ms, last sleep 1.50 ms, last pres -990.00 ms, paint 5.10 ms, queue count 4, SOP 177, EOP 465, RawFRRatio 1, dropped 38, drawn 24289

 

[mm1352000]

...which is probably because something has blocked it for 900ms - which could be MP, the OS, video drivers, some other driver hogging the system etc.

So worth trying to find a DPC latency checking tool that will run on Windows 8, right?

[edit: and maybe worth thinking about updating or trying alternative drivers
@Snoopy87
In one of your earlier posts I think you mentioned that the problem is more prevalent with HD channels. Can you confirm - is that true?]

 

[Owlsroost]

So worth trying to find a DPC latency checking tool that will run on Windows 8, right?

Yes.

 

[Vasilich]

http://www.resplendence.com/latencymon
LatencyMon supports the following operating systems:

• Windows 2012 Server 32-bit editions

• Windows 2012 Server x64 editions

• Windows 8 32-bit editions

• Windows 8 x64 editions

• Windows 2008 Server 32-bit editions

• Windows 2008 Server x64 editions

• Windows 7 32-bit editions

• Windows 7 x64 editions

• Windows Vista 32-bit editions

• Windows Vista x64 editions
  NOTE: Because LatencyMon relies on ETW tracing it does not support any version or edition of Windows XP or Windows 2003 Server.

 

[Snoopy87]

So please can you first clarify if you meant 13:46:57 or 13:47:57. Then we can discuss further...

Sorry! Of course I meant 13:46:57 ;-)

 

[mm1352000]

Sorry! Of course I meant 13:46:57 ;-)

Okay, so then working theory is that sometimes the symptoms are caused by the EPG grabber.

Now I have some follow up questions...

I think you said that you use RAM disk for the timeshift files. Please confirm.
Also, lets talk about your TV Server database.
You're using MySQL 5, and it looks like the database is running on the HTPC.

• Where is that database hosted and how fast will access be? (ie. which HDD/SSD, specs of HDD, how full is it, what other applications might be using it...)
• If the database is hosted on HDD, can you tell if it might need to spin up for the EPG data update?
  
• How many schedules do you have?
• How many channels do you have?

Thanks in advance...

 

[Snoopy87]

Yes, I'm using a 4 GB RAM disc, but the issue is also with timeshift on my SSD.

My current hardware:
- ASrock FM2A85X Extreme-M
- AMD A4-4000
- 2x 4GB DDR3 1333 Corsair XMS3
- 1x 120 GB ADATA SSD
- Digital Devices CineS2 6.5
- iMON 310

The issue also occured with an ASUS E45M1-M PRO (AMD E2), TBS 6922, Sandisk 64 GB SSD.

I never installed anything else on my HTPC. Only the OS (Win 7 and now Win 8), drivers, all updates, MP, MP Extension, etc.

Windows Updates are set to manually download and install. I always make sure that no unneccessary processes are running in background. WinSAT is disabled. Windows Defender is disabled too.

MP and MP Server are installed in default configuration. Both are running on the same HTPC. So I'm using the default DB and nothing else is using this DB.

I never had any schedules or recordings. I am only watching live TV or movies.

In All Channels I have 1178 channels (Astra 19.2 E), but I am not using this list and it is also hidden in MP. In my groups I have totally ca. 100 channels and EPG Grabber is set to only load EPG from grouped channels.

Attached are logs from today with a lot of issues. I will now go back to the original TSWriter and TSReader, because I never had so many issues like the last two days.

 

[mm1352000]

...

In my groups I have totally ca. 100 channels and EPG Grabber is set to only load EPG from grouped channels.

To be clear, can you confirm the values of these two settings:

1. Grab EPG only for channels on same transponder.
2. Store data only for selected channels.

Attached are logs from today with a lot of issues.

Again, I think there are a mixture of issues here.
For the server side, there are continuity errors in the TsWriter log which correspond with the EPG grabber at around 14:30:37. However there are also continuity errors which are clearly not caused by the EPG grabber at 14:47:09, 14:47:12, 14:57:46. So we add a potential third issue to the list: isolated continuity errors (ie. not EPG grabber related).

I will now go back to the original TSWriter and TSReader, because I never had so many issues like the last two days.

I can't speak on the content of the modified TsWriter so I don't know if they have anything to do with it. What I would say is that it is critical to do the DPC latency test while you're able to reproduce the problems. To be clear, from my perspective the latency test is the next test to perform in order to make progress.

 

[Owlsroost]

Hi Tony,

Sorry for the late respons. I needed a few days to test v3.0.78.0. This version is running also flawless on my system. I can say with certainty that the video continuity errors are gone. Only sometimes a few audio dropouts. Can this be solved by using MPAR?

Regards,
Nico

Re. the MPAR/audio dropouts - MPAR by itself won't help (at least I don't think so), but the linked MPAR+TsReader+dshowhelper I've been working on should fix that problem. As soon as I've got a version that I'm happy to let someone else try I'll be in touch (the code keeps getting out-of-date relative to MP master version, and I don't want to give you an 'old' version).

 

[Owlsroost]

...

In my groups I have totally ca. 100 channels and EPG Grabber is set to only load EPG from grouped channels.

To be clear, can you confirm the values of these two settings:

1. Grab EPG only for channels on same transponder.
2. Store data only for selected channels.

Attached are logs from today with a lot of issues.

Again, I think there are a mixture of issues here.
For the server side, there are continuity errors in the TsWriter log which correspond with the EPG grabber at around 14:30:37. However there are also continuity errors which are clearly not caused by the EPG grabber at 14:47:09, 14:47:12, 14:57:46. So we add a potential third issue to the list: isolated continuity errors (ie. not EPG grabber related).

I will now go back to the original TSWriter and TSReader, because I never had so many issues like the last two days.

I can't speak on the content of the modified TsWriter so I don't know if they have anything to do with it. What I would say is that it is critical to do the DPC latency test while you're able to reproduce the problems. To be clear, from my perspective the latency test is the next test to perform in order to make progress.

I agree with mm1352000.

The common thread running through these problems seems to be something in the system causing high CPU spikes and/or high interrupt latencies, so you need to try and find out what that is.

My own 'favourite' culprit is network-related stuff (if I get regular continuity errors, bunches of dropped frames or system freezes on my HTPC the first thing I check is if the network connection is working OK.....)

Also have you checked that the CPU isn't getting too hot ?