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

[mm1352000]

Snoopy87 - have you tried using something like ProcessLasso to lower the process priority of the database engine (MySQL) ?

I found I needed to do this for MS SQL Express years ago - it might help to stop database activity affecting playback.

Tony, as discussed in my investigation results here:
https://forum.team-mediaportal.com/...-lot-of-artifacts.117848/page-23#post-1038562
... I think the EPG issues have nothing to do with the database insert/activity and everything to do with the volume of EPG data collected from the stream and how it is transferred from TsWriter to TV library. We're talking about transferring who-knows-how-many days/hours of EPG (maybe 8 or 14 days???) for ~70 channels in a TS section handling callback. While that is happening, the tuner driver is likely dropping packets because it can't deliver to TsWriter (due to locking etc.) or buffers are simply filling and overflowing and data is lost that way. Potentially this could be tuner-dependent behaviour... and it is certainly stream/provider dependent. At least that is my current working theory.

 

[Owlsroost]

Tony, as discussed in my investigation results here:
https://forum.team-mediaportal.com/t...-lot-of-artifacts.117848/page-23#post-1038562

I understood what you were saying earlier - I was just making a suggestion to Snoopy87 of something to try (and which I've had problems with in the past).

While that is happening, the tuner driver is likely dropping packets because it can't deliver to TsWriter (due to locking etc.) or buffers are simply filling and overflowing and data is lost that way.

Agreed - TsWriter needs some multi-threading (it also has a problem I experience of timeshifting stalling while it waits for a 'green' drive to spin up at the start of a recording - so data processing for one drive is being affected by processing for another one).

I'm guessing that there is not much buffering/async queueing of data inside TsWriter ?

 

[mm1352000]

it also has a problem I experience of timeshifting stalling while it waits for a 'green' drive to spin up at the start of a recording - so data processing for one drive is being affected by processing for another one.

Yeah, I also experience that. Had to stop my drives from ever spinning down. Not exactly ideal for drive lifetime.

I'm guessing that there is not much buffering/async queueing of data inside TsWriter ?

I've never really looked at the file handling but I would guess that you're right. This part of TsWriter has not changed much [yet] in TVE 3.5.

 

[megahorst]

I have moved from SD-TV to HD-TV and now I have a similar problem.
TV picture jumps from time to time, moves back a second, shows some blocks or the picture freezes while the sound goes on. When jumping back some seconds when the last case happens everithing is fine.
How should I proceed to solve this issue?
I have seen some continuity errors in the tswriter log. But what leads to this errors? I think the signal is ok.
My anti-virus does exclude the timeshift folder and all *.ts files.

I have created logfiles on my tv-server. Does anybody have a hint for me?

 

[mm1352000]

But what leads to this errors?

Almost always:
1. HDD stress, or
2. Bad signal strength/quality.

In your case, my guess is that an HDD was spinning down at the time of the continuity errors in these logs. Can you confirm?

How is your client connected?
Can you please provide log files?

 

[megahorst]

In your case, my guess is that an HDD was spinning down at the time of the continuity errors in these logs. Can you confirm?

How is your client connected?
Can you please provide log files?

Thx for having a look!
I will capture logs tomorrow.

The server is located in my cellar. Because of this I'm not sure about the hdd. Network connection is gbit Ethernet.

 

[megahorst]

I have managed to capture the logs on server and client in parallel..
I have disabled hdd spindown in windows energy settings, but the continuity errors are not gone.

 

[megahorst]

I did a lot of testing during the last days.

Mainpoint: In my case bad cable signal is the source for most problems. I have done some adjustments at the cable amp and is better now, but still not perfect. It is not so easy without measure equipment. But this is truely my job. In the tv server config I can see the signal quality, but not the signal level. Is it possible to see this within a logfile?

What I have also mentioned:
I have watched one of the problem channels at my 1.60 pre client and have had a look to the discontinuity counter in the config tool of the server. (section manual control)
I have seen that only one dropped packet can lead to a stopped tv playing at the client. I have to stopp tv at the client to have it working again. Onetimes stopping was not possible and I had to kill MePo at the client.
Should I try to capture logs or is rthis working as designed?

I have also seen stuttering (one or two times) when there was no dropped packet mentioned at the server side.

At my 1.50 client I did not see one of these.

 

[Owlsroost]

In the tv server config I can see the signal quality, but not the signal level. Is it possible to see this within a logfile?

Yes - it's in TVserver.log (but the numbers don't mean very much, because there is no standard for it...)

Should I try to capture logs or is rthis working as designed?

No, it shouldn't stop, so try and capture some logs. Sometimes data errors can cause video decode filters to hang/stop.

What kind of network are you using ?

 

[megahorst]

No, it shouldn't stop, so try and capture some logs. Sometimes data errors can cause video decode filters to hang/stop.

Here we are, it happened 11:53 and 11:59 again. TV stopped and I had to restart it.
All this happened at my 1.60 pre client connected with Gbit ethernet.