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

[mm1352000]

I already posted logs. If you need other logs, please tell me which logs you are need and what you want to see in those new logs which is not shown in my previously posted logs ;-)

Yep, I know... and thanks for that.


My point was... you said that other people were also experiencing the same problem, but I've seen few reports with logs that would allow us to confirm your report. In other words, I'm trying to see whether the problem is specific to your system or not.

I'm a C# developer since many years and I also develope commercial software since 10 years, so I know how to find bugs! I investigated a lot (!) of time to find the issue, and I also posted very detailed error reports! But no one is listening to me, because the MP team don't want to help and always tell me, that MDAPI is the issue.

I'm certainly listening else I wouldn't be making this comment.
From my perspective, I have a problem with the fact that you seem to refuse to perform any test to eliminate MD as the cause. I don't know why you've made that choice... but effectively it means we are limited in what we can do. You know the policy...

I also posted that I have the same effect as Mister Bean, that the same scene has no artifacts, if I rewind the timeshift buffer. So it CAN'T be MDAPI Plus, because otherwise the timeshift/recording stream has the artifacts too.

But as I said above, Mister Bean said when he disabled MD the problem went away. That points to MD being the problem! This is why I keep asking you to do the same test!

Also there is a big difference between MDAPI filter and MDAPI Plus.

Okay. To be clear, I don't use MD - never have - but I don't need to know about the differences. I'm suggesting to try to find the problem by process of elimination. MD is one thing that must be eliminated as cause.

If MP 1.2 and MDAPI Plus work great, and MP 1.3 and MDAPI Plus work not great, which of those both application causing the issue? In my opionion it's very clear...

Okay... so perform the test to prove that the problem is with MP 1.3 and not with MD. To do this, all you have to do is show that the problem is still present with MP 1.3 when you don't use MD.

As said I'm very interested in fixing the issue, because my friend, a lot of people in the german MP forum and I can't watch TV with those issues.

Are you talking about this thread?
https://forum.team-mediaportal.com/threads/ständing-aussetzer.115432/

I checked it this morning and nobody except you seems to have posted logs. Also, everyone seems to be saying different things. It is impossible for us to investigate such reports...

So just send me debug versions or what every you need to find the issue and I will send you the results ;-)

The first test to perform is to perform the test with MD disabled. Please perform this test and send the results.

 

[Snoopy87]

Thanks for your help and reply!

The problem is, that it is very, very difficult to find out, if MDAPI is the cause, because at the moment the artifacts only appear 1x per week, after I upgraded my hardware. I never saw this issue on SD channels, so if this only occurs on HD channels, there are only 2-3 HD channels, which are not encrypted, so my girlfriend and I have to watch those 2-3 channels for at least 1-2 weeks, but we would never watch those channels in normal case, so it would be a very hard week... :-D It would be much easier, if the artifacts were always present so that you can test if they were gone, after disabling mdapi.

Is there no other way to find out if mdapi is the cause for those problems? Maybe something special in MP or MDAPI log files?

Do you have any idea, why the artifacts are gone, if I watch the same scene twice? MDAPI is not encrypting in this case, it's just a playback of the already recorded timeshift buffer.

In the past I also recorded a scene with artifacts. Then I go to My Recordings and played the file with MediaPortal and sometimes I saw the artifacts, and sometimes not. With Windows Media Player the artifacts were never shown for the same recorded file, BUT sometimes a short video or sound freezer for just a few milliseconds.

So my theory is: If there is any issue in the stream (errors, encryption errors, missing frames, etc. ) the playback of Live TV or the recorded file get mixed up. This makes sense to me and explains why the same recording/timeshift works if you try to play it again a few times.

But yes, I will try to disable MDAPI.... but as said in my case it is no guarantee that this was the cause, because it could also be that this will not happen on SD channels and without MDAPI I can only watch SD channels (exception the 2-3 HD channels I mentioned above).

Regards,
Sascha

 

[Mister Bean]

Hi mm1352000,

Thanks for your respons. This is my first post in this section indeed, but that's because i was a very satisfied MP-user When I have time, I will post logs and provide you with all other relevant information. But the problem is exact the same as driver140771 has described here https://forum.team-mediaportal.com/threads/livetv-freezes-and-shows-a-lot-of-artifacts.117848/page-2 Lots of video continuity errors.

To be continued. At the moment I'm enjoying the weather here in the Netherlands

Regards,
Nico

Hi Tony,

I have finally found a solution to solve the video continuity errors. When I'm using your tsreader 'TsReader_300msAudio_patched_2.zip' posted here: https://forum.team-mediaportal.com/threads/experimental-tsreader-development.102693/ the video continuity errors totally gone!!

I'm running a multiseat setup with Argus-TV using UNC-paths.
Question: Is 'Tsreader_300msAudio' also buffering more video-data at startup? If not, why are the video continuity errors gone when i'm using this version?

At the moment I'm strugling with the '200msec dropouts' posted here: https://forum.team-mediaportal.com/threads/continous-glitches-in-livetv-both-sd-hd.83762/ and here https://forum.team-mediaportal.com/...-log-zeigt-dabei-pause-200ms-renderer.100874/ This is caused by an audio buffer underrun <100msec. This can be solved by stepping Live TV 5 seconds back. In that case Live TV is absolutely perfect!

So there is progress on this

Regards,
Nico

 

[Owlsroost]

Question: Is 'Tsreader_300msAudio' also buffering more video-data at startup?

Yes, but you can do the same thing with the standard MP 1.4/1.5 version (from the experimental TsReader thread):

New feature: Registry key added to adjust data buffering time - HKEY_CURRENT_USER\Software\Team MediaPortal\TsReader, set "BufferingDelayInMilliSeconds" to a (decimal) value in milliseconds (range is 0 to 2000, default is 0). Note - this will add delay to live TV channel changes since it needs to build up the buffer before play starts.

At the moment I'm strugling with the '200msec dropouts' posted here: https://forum.team-mediaportal.com/threads/continous-glitches-in-livetv-both-sd-hd.83762/ and here https://forum.team-mediaportal.com/t...-log-zeigt-dabei-pause-200ms-renderer.100874/ This is caused by an audio buffer underrun

TsReader.ax is running out of data, so it has to pause playback for 200ms to build up the data buffer again - usually it's because the PC playback 'clock' is running faster than the broadcaster 'clock'.

 

[Mister Bean]

Hi Tony,


Now it gets interesting! I've tried tsreader 'noStopMod68'. Once without buffer delay, and once with 300msec buffer delay. In both cases the video continuity errors are back! The only tsreader with give me no video continuity errors is 'TsReader_300msAudio_patched_2.zip'. I think the video continuity errors are not caused by a video buffer underrun. So, something else in tsreader is triggering the video continuity errors.

Do you have an idea? What else more is different between the two tsreaders? I'm afraid I'm not the only one who has problems with video continuity errors when Argus TV is used as TV-server (only UNC-paths), because these problems occur on all HTPC-systems I have build (Single-seat/multi-seat, Intel based/AMD based). I'm using UNC paths, because RTSP implementation of Argus is buggy (terrible slow zapping).

Maybe is has something to do with the 'tswriter' of Argus TV.

Logs are attached.

Looking forward to your respons.

Thanks in advance.

Regards,
Nico

 

[Owlsroost]

What else more is different between the two tsreaders?

Lots - the '300ms' version is nearly 2 years old....in particular the way the current versions read data from files - including UNC paths - is different (they use a separate thread, and always try to maintain the original amount of buffered data).

Can you repeat the test using the TsReader.ax version here - https://forum.team-mediaportal.com/...ader-ax-ac3-improvements.121225/#post-1023340 - (this version is built from the very latest codebase).

 

[Mister Bean]

Hi Tony,

I've tested V74 (with 300msec buffer delay). Also video continuity errors! See log. I'm very curious what in tsreader is triggering the video continuity errors. A needle in a haystack? because lots of changes are implemented in tsreader over the last two years . . . .
But, i'm convinced tsreader is the culprit here or (buggy) Argus-TV/UNC-paths ;-)

Any other ideas?

Regards,
Nico

 

[mm1352000]

Nico, could you also provide the Argus log files? Maybe we can tell something from them. If they are re-writing the PCR then it might explain what is happening.

 

[Mister Bean]

Hi mm,

Here they are (see attachment below). It is a little bit a mess, but recordercard 3 is used during testing this morning. And yes . . . i'm using MD**I, but that is not the culprit here. Video continuity errors are also occuring when MD**I is not part of the filtergraph (when totally switched off and unregistered).

BTW, what is PCR?

I'm almost convinced that we are now very close to an solution of this annoying problem! Hopefully we have now theopportunity to make all (dutch) Argus-TV users happy ;-)

Regards,
Nico

 

[mm1352000]

Here they are (see attachment below). It is a little bit a mess, but recordercard 3 is used during testing this morning.

Hmmm, I don't see anything equivalent to the TsWriter info in any of the log files (in other words, nothing is useful). Maybe it is because the logs are set to "info" rather than "debug"?

BTW, what is PCR?

Program clock rate.