LiveTV freezes and shows a lot of artifacts (2 Viewers)

[Owlsroost]

There's two things that stand out in the logs:

1. The client PC render 'clock' is apparently running 0.2% (2000 ppm !) faster than the broadcast stream - this is why the client TsReader.ax runs low on data so quickly, it 'loses' 0.5 sec of buffered data over a 4 minute period. This is a huge clock rate error. Does the same thing happen on all clients ? (or on the server if you watch TV locally ?)

2. When the continuity errors occur, it always seems to be one packet missing (the continuity counter is modulo 16):

[2013-08-27 11:55:23,307] [18c03bf0] [ c14] - Video Continuity error... 2 ( prev 0 )
[2013-08-27 11:55:23,499] [18c03bf0] [ c14] - Video Continuity error... 1 ( prev f )
[2013-08-27 11:55:23,694] [18c03bf0] [ c14] - Video Continuity error... 6 ( prev 4 )

(the other logs show the same symptom).

 

[Mister Bean]

mm,
I'm afraid it is not possible to change the log verbosity / log level in Argus TV :-( I can find this setting anywhere. I can only find two xml files in the program directory where you can possible change something (see attachment). I've never tried this.


Tony,
Thats interesting!

1. How is it possible that the PC render clock is running so much faster than the broadcast stream? Maybe the broadcast stream is simply running too slow ;-) Is it possible to adjust the PC render clock? BIOS settings, or . . . ? On the other side, I'm at this moment not convinced that this is causing the microstutter/pixelation (video continuity errors), because these video continuity errors are gone when I'm using the old 300ms tsreader. I think we have to deal with two problems: video continuity errors and clock mismatch/drift between broadcast stream and renderer. I do not know if there are dependencies between these two problems.
The video continuity errors happen on all my clients (laptop, HTPC living room, PC homeoffice). I have tried to install Argus-TV locally on my HTPC (has also a DVB-S2 card) and what do you think? Also video continuity errors! It seems that (the latest versions of) tsreader and Argus TV are not a good 'marriage'. Maybe there is work to do on Argus TV-client side.

The clock mismatch doesn't bother me so much (can be solved by timeshifting 5 seconds back when using the 300ms tsreader). But the video continuities does! These are very annoying (pixelation) while watching tv.

2. Here I'm lost . . . Can you explain further?

Do you have further suggestions?

Thanks,

 

[mm1352000]

I'm afraid it is not possible to change the log verbosity / log level in Argus TV :-( I can find this setting anywhere. I can only find two xml files in the program directory where you can possible change something (see attachment). I've never tried this.

Hmmm, that is unfortunate.

Do you have further suggestions?

If you really want to consider all the options for solving this problem, I think it would be worthwhile to try installing MP TV Server on one of the PCs with a TV card. Not having access to good logging or source code on the server side is a limitation from my perspective. With TV Server obviously we have access to the source code, control over the logging, and we know the combination of TsWriter + TsReader should work. This will [hopefully] allow us to eliminate either TsReader or Argus "TsWriter" as the cause.


mm

 

[Owlsroost]

2. Here I'm lost . . . Can you explain further?

I was thinking out loud really

Basically, the data is contained in an MPEG 'Transport Stream', divided up into 188 byte packets. Every packet has a 4 bit 'continuity counter' value which is incremented for each new packet, so anything which is receiving the packets can work out if any are missing. When TsReader.ax finds that the value in the packet doesn't match what it expects, it puts a 'continuity error' message in the log.

The interesting thing is that it appears to be losing just one packet approx. every 200 ms, but only when the file reading is very close to the front (most recent part) of the timeshift file i.e. there is a pattern to it....

Could you post a longer log, so we can check if the 'continuity errors' keep happening in the same way ?

 

[Owlsroost]

If you skip back (or pause) for a few seconds, do you get the continuity errors ?

 

[Mister Bean]

Hi mm,

Thanks for your reply. I will consider a migration to MP-TV server. In the past there were a few disadvantages with MP TV-server. I can't remember exactly, but the main issue was a unstable/unreliable DVB-EPG here in the Netherlands (Canal Digitaal). FTR/Argus does DVB-EPG fantastic.


Hi Tony,

Thanks for your explanation. Yesterday evening I did some testing. I'm not really sure, but it seems that all old TsReader versions (MP121, 122) don't have problems with video continuity errors. Yesterday I've watched TV the whole evening, zapped frequently between channels (mainly SD-channels). The TsReader of MP121 (version v0.4.12 or version v0.4.14?) gave me supersmooth television without audio dropouts and video continuity errors. Strange . . . .

All new versions of TsReader are producing video continuity errors (with Argus TV and UNC paths), that's for sure. Skipping back/timeshifting do not solve this problem.

At the moment I'm at work. Tonight I will do some more testing.

To be continued!

Regards,
Nico

 

[mm1352000]

I will consider a migration to MP-TV server...

To be clear, I'm not asking you to migrate - just to install it for testing.

 

[Mister Bean]

hi mm,

Clear But . . . I always understood that UNC-paths are not officially supported by the team, right? When I switch over to RTSP the video continuity errors are gone. With Argus TV is that not an option for me because Argus' bad RTSP implementation (terrible slow zapping).

 

[Mister Bean]

Hi Tony,

I'm back . Yesterday evening and this evening I did some tests with old TsReader versions. These versions are running definitely better with Argus TV then the new versions. I haven't seen video continuity errors or annoying pixelation/microstutter anymore. Unfortunately audio is sometimes dropping (very short dropouts are hearable). I think this is caused by the (huge) clock mismatch between provider and (audio)renderer. Audio-connection is HDMI --> Onkyo AV-receiver. Maybe an alternative audio renderer gives any improvement (SPDIF connection instead of HDMI). BTW the audio dropouts are disappearing when skipping back/timeshifting. Are those audio-dropouts related to the video continuity errors in the new TsReader versions?

Attached some logs for further analysis.

Thanks in advance.

Regards,
Nico

 

[mm1352000]

I'm confused. Let's take this one comment at a time.

I always understood that UNC-paths are not officially supported by the team, right?

Use of UNC paths for timeshifting in a multi-seat environment with TV Server is a debug option. People who have trouble with RTSP or prefer UNC use it. Yes, it is a debug option... but I don't think anyone would make a big deal over support.

When I switch over to RTSP the video continuity errors are gone.

So to be clear, that is multi-seat MP TV Server + MP client with Argus scheduler plugin installed on the server?
Do you have issues using the UNC option with MP TV Server?

With Argus TV is that not an option for me because Argus' bad RTSP implementation (terrible slow zapping).

Are you saying that Argus TV Server + RTSP, MP TV Server + RTSP, and MP TV Server + UNC are okay, and that only Argus TV Server + UNC is a problem?