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

[Snoopy87]

Hi,

with the latest TSReader TV playback suddenly stopped 2 times. No stuttering, directly hard stopped the playback and also stopped the Timeshift. See logs attached (11:19 and 12:15).

 

[Owlsroost]

I can't see anything obviously wrong in the logs - when exactly did the 'stops' happen ?

 

[JackTramiel]

Just upgraded to 1.5 without saving my logs from yesterday, but i had a freeze too. We were watching Pro7 and suddenly
the pictured stopped. I waited a few seconds and then jumped back in timeshift. After another few secondes the playback continued.
I was reading the logs on the fly and could not find any entry when the picture freezed.

I ll post logs when it happens again.

 

[Owlsroost]

Just upgraded to 1.5 without saving my logs from yesterday, but i had a freeze too. We were watching Pro7 and suddenly
the pictured stopped. I waited a few seconds and then jumped back in timeshift. After another few secondes the playback continued.
I was reading the logs on the fly and could not find any entry when the picture freezed.

I ll post logs when it happens again.

Is this using the standard MP 1.5.0 TsReader.ax ?

 

[JackTramiel]

The freeze was 1.3 with your latest tsreader from this thread. Upgraded this morning.

 

[JackTramiel]

Attached logs with MePo 1.5 and v76. Just let live tv running and had a look now and then. There have been small artefacts, did not notice more issues.
I can see a lot of continuity errors in the tsreader.log.

 

[Owlsroost]

Attached logs with MePo 1.5 and v76. Just let live tv running and had a look now and then. There have been small artefacts, did not notice more issues.
I can see a lot of continuity errors in the tsreader.log.

Yes - it's probably the RTSP 'dropped packets' problem, which is usually caused by networking issues - I can't tell you any more than that.

The same networking issues (dropped/corrupted packets) can cause 'late sample' problems when using UNC paths option, because Windows will ask for the missing packets to be re-sent - which can make them late, so they become dropped frames etc.

 

[Snoopy87]

I can't see anything obviously wrong in the logs - when exactly did the 'stops' happen ?

As said in my previous post: 11:19 (around 11:19:37) and 12:15.

 

[Owlsroost]

As far as I can tell, TV server stopped the timeshifting first, then TsReader just ran out of data (as expected in this situation) - from TsWriter log:

03-11-2013 11:19:35.90 EpgScanner::GrabMHW
03-11-2013 11:19:35.90 mhw grab
03-11-2013 11:19:35.90 mhw reset
03-11-2013 11:19:35.90 mhw grabber started decoders:2
03-11-2013 11:19:35.90 CDiskRecorder::Flush() - Throttle to 3760 bytes
03-11-2013 11:19:35.90 CDiskRecorder::Flush() - Throttle to 6016 bytes
03-11-2013 11:19:35.90 CDiskRecorder::Flush() - Throttle to 7520 bytes
03-11-2013 11:19:35.122 CDiskRecorder::Flush() - Throttle to 9400 bytes
03-11-2013 11:19:35.137 CDiskRecorder::Flush() - Throttle to 15416 bytes
03-11-2013 11:19:35.153 CDiskRecorder::Flush() - Throttle to 32336 bytes (max)
03-11-2013 11:19:36.971 epg: reset
03-11-2013 11:19:36.972 epg:ResetEPG()
03-11-2013 11:19:36.974 mhw reset
03-11-2013 11:19:37.42 Recorder: TIMESHIFT Stop 'R:\\live3-0.ts.tsbuffer'
03-11-2013 11:19:37.106 Recorder: TIMESHIFT Reset
03-11-2013 11:19:37.117 CDiskRecorder::Reset() - Reset write buffer throttle

....and from TsReader log:

[2013-11-03 11:19:38,146] [ 65c0048] [ e64] - Demux : Video to render 2.587 Sec
[2013-11-03 11:19:42,967] [ 65c0048] [ da4] - CTsReaderFilter::Duration - correction to predicted duration: 1893.000
[2013-11-03 11:19:47,251] [ 65c0048] [ da4] - CTsReaderFilter::Duration - correction to predicted duration: 1893.000
[2013-11-03 11:19:51,536] [ 65c0048] [ da4] - CTsReaderFilter::Duration - correction to predicted duration: 1893.000
[2013-11-03 11:19:55,820] [ 65c0048] [ da4] - CTsReaderFilter::Duration - correction to predicted duration: 1893.000
[2013-11-03 11:19:56,277] [ 65c0048] [ 9ec] - CTsReaderFilter::Pause() - IsTimeShifting = 1 - state = 2
[2013-11-03 11:19:56,277] [ 65c0048] [ 9ec] - CTsReaderFilter::Pause() - END - state = 1

(the 'correction to predicted duration' messages are because the timeshift buffer file has stopped growing)

TsReader.ax does not control TV server - that is done by the MP TV plugin/player, so it's hard to see how the new TsReader could have caused the 'stops'. I don't know what might have caused TsWriter to stop the timeshifting - I'm not a TV server expert.

 

[Snoopy87]

Very strange. I never ever had this issue. And then within 2 hours I had this issue twice with v2 of your latest TSReader. I then switched back to the v1 TSReader and until now I also still hadn't this issue anymore So at the moment I will use v1 for testing.