Stuttering on Live-TV - since 1.2 (1 Viewer)

[jimbeam128]

MediaPortal Version: 1.2.1 final
MediaPortal Skin: PureVisionHD Blue
Windows Version: XP SP3
CPU Type: Athlon X2 4850e
HDD: 32 GB SSD + 500 GB HDD
Memory: 6 GB DDR2
Motherboard: Asus M3N78-VM
Video Card: Gainward Geforce 9400 GT 1 GB
Video Card Driver:
Sound Card:
Sound Card AC3:
Sound Card Driver:
1. TV Card:
1. TV Card Type: DVB-C
1. TV Card Driver: 1.01.01.501
2. TV Card: Terratec Cinergy C PCI HD
2. TV Card Type:
2. TV Card Driver:
3. TV Card:
3. TV Card Type:
3. TV Card Driver:
4. TV Card:
4. TV Card Type:
4. TV Card Driver:
MPEG2 Video Codec: Power DVD 9
MPEG2 Audio Codec: AC3Filter
h.264 Video Codec: PowerDVD9
Satelite/CableTV Provider: Unitymedia NRW
HTPC Case: Suitcase out of Hardware-Store
Cooling: 2 low noise Fans
Power Supply: Silentmaxx 350w
Remote: Logitech 525
TV: Samsung 32" LCD
TV - HTPC Connection: HDMI


Hello,

we experience stuttering when watching Live-TV since MePo 1.2
Some users reported and discussed this in the german forum.

Here the link of the discussion in the german forum:

https://forum.team-mediaportal.com/tv-streaming-480/mepo-1-2-und-ruckler-bei-tv-tsreader-log-zeigt-dabei-pause-200ms-renderer-100874/

What we can say is that the stuttering happens max. 5 minutes after starting or switching a channel. That stuttering or "hanging" is very short.

Attached a log-file from my system, where it happened. What I can say is that when the stutterin occured, the last log entries are these here:

12-10-2011 19:17:19.656 [138]Demux : Audio to render 0.138 Sec
12-10-2011 19:17:19.796 [cb8]Demux : Video to render 0.526 Sec
12-10-2011 19:17:20.281 [138]Demux : Video to render 0.524 Sec
12-10-2011 19:17:21.593 [cb8]Demux : Audio to render 0.112 Sec
12-10-2011 19:17:26.656 [138]Demux : Video to render 0.506 Sec
12-10-2011 19:17:32.828 [138]Demux : Video to render 0.505 Sec
12-10-2011 19:17:34.812 [cb8]Demux : Video to render 0.395 Sec
12-10-2011 19:17:40.312 [cb8]Demux : Audio to render 0.112 Sec
12-10-2011 19:17:44.171 [138]Demux : Audio to render 0.096 Sec
12-10-2011 19:17:44.171 [138]Demux : Audio to render too late= 0.096 Sec, rendering will be paused for a while
12-10-2011 19:17:48.390 [98c]Pause 200mS renderer clock to match provider/RTSP clock...
12-10-2011 19:17:48.390 [98c]CTsReaderFilter::Pause() - IsTimeShifting = 1 - state = 2
12-10-2011 19:17:48.390 [98c]CTsReaderFilter::Pause() - END - state = 1
12-10-2011 19:17:48.593 [98c]CTsReaderFilter::Run(332405.54) state 1 seeking 0
12-10-2011 19:17:48.593 [98c]Elapsed time from pause to Audio/Video ( total zapping time ) : 203 mS
12-10-2011 19:17:48.593 [98c]CTsReaderFilter::Run(332405.54) state 2 -->done

Those log-entries say that "rendering will be paused for 200ms". From my point of view that stutter occurs for 200 ms.

I compared the history of Logfiles from my 1.1 Installation to the logs of the 1.2.1 Installation. I took a look on ALL old logfiles an compared them to the new ones from the 1.2.1 installation. I can find that behaviour on some log files, but really just a few files. And I searched on log-files for over a year!
This "error" occured on some logfiles of the 1.2.1 installation over 10 times in about 3-4 hours - That pretty much.

I can say that this stuttering did not occur on the 1.1 installation. And I can proof it with logfiles.

Please work on that Issue, because due to the fact that there are other users who experience the same behaviour, this seems to be a general Issue.

I hope you can fix that Issue. That stuttering really sucks.

 

[tourettes]

I have seen quite similar issue with the 1.2.0 / 1.2.0 - MP Audio renderer is running out of the audio data quite often after changing a channel or starting live tv.

Please test different Tsreader.ax versions from the past year. I have attached the most interesting ones.

1) unzip the zip content to some folder
2) start up command promt with adming rights
3) go to the folder where files were unzipped
4) register one filter with regsvr32 - for example "regsvr32 TsReader-26539.ax"
5) test tv for stuttering

repeat #4 & #5 for all different TsReader versions. In the end you should restore the original TsReader from \Program Files\Team MediaPortal\MediaPortal folder with "regsvr32 tsreader.ax"

 

[Owlsroost]

Awaiting the testing results with interest....

Tony

 

[FloMann]

AW: Stuttering on Live-TV - since 1.2

Hello,

first, thanks to jimbeam for starting the Thread in this forum section.
I also have this Problem with MePo 1.2.x RC or Final, bevor i use ~ 1,5 - 2 Years MePo 1.0.2 and for few month MePo 1.1.3.
With the older MePo Version 1.0.2, TV (streaming)stability works near perfect and very smooth with my HW Setups.
MePo 1.1.3 was used for few month, in this time i dont see the Problem in daily use of TV. Later I directly compared MePo 1.1.3
to 1.2, the Logs from MePo 1.1.3 TsReader shows in principle the same, that Audio to Render runs out of Time,
but slower than in MePo 1.2 and so it takes longer(sometimes 2.5-4hours) after Zapping, till TsReader triggers Pause Renderer for 200ms.
This was not so perfect like MePo 1.0.2, but in daily use, less less less annoying as with MePo 1.2..

I remind some Threads from the Past where users has Stutter Problems, espacially with the (german) "Pro7 Media AG" Stream,
in this case, later in one of these threads(linked in Mantis link below), i read the first time about the Pause 200ms Renderer to prevent
extreme Stutterring.
Mantis says since MePo 1.1RC2 officially, this problem (clock drifts Broadcaster and System) where workaround in MePo TsReader Code.
http://mantis.team-mediaportal.com/view.php?id=2239

So MePo 1.0.2 dont show this Audio/Video to Render delay/buffer callculation between Provider/Broadcaster and my System in the TsReader
log, or paused Renderer for 200ms, because it dosent exists in the Code. For me, this was the last MePo Versions i tryed that works perfect
in this behaviour. MePo 1.1.3 works ok, but as i said, here is principle the same running out of Audio/Video to Render but for me not so
problematic in daily use of TV. Normaly in this longer time period till pause 200ms Renderer occurs, i zapped to another Channel or used
Timeshifting.

Starting TV with first tune to a channel, normaly has more Audio to Render Time, as after zapping, and so it takes longer till Pause 200ms
Renderer occurs.
Especially with MePo 1.2 sometimes the Audio to Render ist directly after zapping under the treshhold (Audio 0,1s /Video 0,2s) or yet negativ,
log`s shows, the pause 200ms will be triggered ~30sec.after the Audio to Render underflow Message, but in this ~30sec. TV works normaly
so i can see. When I use Timeshifting (e.g. paused TV for some sec or longer) principle TV Works great over hours with no Problems, also
when i jump to the end of the Timeshift buffer, logs show`s seconds(1-3sec) of Audio to Render buffer/delay and so it tooks very long to run
under threshold.

In this Thread I posted two TS Reader Logs from MePo 1.2RC where in the first one this problem often occurs between the first 5 minutes
after zapping.
https://forum.team-mediaportal.com/...dabei-pause-200ms-renderer-100874/#post792612

Here are two TS Reader Logs from MePo 1.1.3 and 1.2RC, they shows starting TV and five Zappings with some time between(most 5min interval).
https://forum.team-mediaportal.com/...dabei-pause-200ms-renderer-100874/#post795587

Also strange(for me) is that normaly in the beginning after Zapping the Audio to Render is running out faster and over the time it is running
out slower, generally the running out of Audio to Render buffer looks for me sometimes a little jumpy.
Strange because i dont think Povider and System Clocks changes that way in this time. So i think normaly it must run out more even, when
there is really only the Provider/System Clock difference and e.g. the system Renders video/audio faster because of the some ppm faster
System clock base than Provider clock. Also there are differences between MePo Versions, so i think it cant be only the Clock base
differences between Provider and System.
I know that principle it can be a problem on PC's when the Systems Clock base for rendering Video or Audio is some PPM higher and works
so a little bit faster than the mediaspeed of recieved streams, in this case long time perfect TV streaming gives only with syncronisation
between this Provider and System clocks.
ArionP wrotes in an older Thread this actually cant be performed on PC's, because e.g. not fine enough clock tuning on Videocard refresh
rate. So I also think, a great enough buffer helps here when necessary, but first big enough for some hours and then more stability over the
time(best only the real differences between this clocks have influence).. I think it was this thread, older but here some users have also
Problems with the Pause Renderer 200ms behaviour.
https://forum.team-mediaportal.com/...-glitches-livetv-both-sd-hd-83762/index5.html

I attched some other logs from MePo 1.2 TsReader which also shows negativ or under Threshold Values for Audio to Render directly after
zapping and ~30sec later triggerd Pause(7:52 and 10:54).
Dont take care about errors at about 11:50-11:55, here was the Clickfinder EPG Plugin the problem, not the plugin itself, the slow import
works well, the TV stream errors occurs when clickfinder cleans his own database after downloading new data, this results in hard HDD use.
To hard for my actually used HDD with MePo TV and clickfinder cleaning worked at the same time.


Actually i use the TsReader 25639 from Tourretes Paket above (Post #2), my plan is to test every TS Reader(from old to new one) for a
one/two or three days in daily use and report back when i exactly know whats going on.

Thanks
Florian

 

[jimbeam128]

AW: Stuttering on Live-TV - since 1.2

Actually i use the TsReader 25639 from Tourretes Paket above (Post #2), my plan is to test every TS Reader(from old to new one) for a
one/two or three days in daily use and report back when i exactly know whats going on.

I´ll do the same and then give feedback in a few days....

By the way,

do we have to exchange the tsreader - file, or is it really enough just to register the other file(s)?

I´ve tested through all tsreader files as described, but stuttering still occurs after channel change.

Just to confirm:

I´ve just registered the file and then tested it.

Do we have to exchange the testfile with the file in the program files folder? - I´m not sure if the files were really used...

 

[mm1352000]

Re: AW: Stuttering on Live-TV - since 1.2

By the way,

do we have to exchange the tsreader - file, or is it really enough just to register the other file(s)?

If you want to be sure that the files were used then I think better to take a backup of your current TsReader (rename to TsReader.ax.bak or something) and then rename the version you want to test to TsReader.ax while you test it (make sure to restart MP). That is just the way I do it though...

mm

 

[FloMann]

AW: Stuttering on Live-TV - since 1.2

Hello,

Now, i tested the TSreader 26539 for some time, i have rename (.bak) the original and copy the (renamed)TSreader 26539 in the
MePo folder, i checked the Graphs (graphstudio/Graphedit) and also the properties, the replaced TSreader is used, so
the replacement was succesfull.

The Problems with running out of Audio to Render and triggered Pause 200ms Renderer still occurs,
i attached some Logs from TS Reader 26539.

In the Log from yesterday (16.10.11), during Clickfinder Update (12:32 - 12:47) is working,
some Stream Errors ocuurs. Principle normal for my setup, when Clickfinder Cleans up his own Database, but this time,
the errors also occurs during Clickfinder Plugin Slow Import in MePo Database, and also some errors after
Clickfinder EGP Update is finished. I dont know why, in the past few weeks with MePo 1.2 and his original TS Reader
i only see stream erros when Clickfinder itself update and cleans his own database, after this time normaly no further errors occurs.
This is is another Problem, but only for information i also attached TV Log, here are some log entries at this time for update the
EPG with Clickfinder, so i think this shows that this stream errors correlate with EPG Update.

Now i want test the next TS Reader 27333, but JimBeam wrotes it do not help, so i have no hope, but i try it.

Is it possible for someone to compile me two TS Reader Filter without execute a Rendering Stop for 200ms.
Comment Out or change this marked lines in TSReader.cpp, so i think thats unproblematic and Pause will not be execute

void CTsReaderFilter::SetMediaPosition(REFERENCE_TIME MediaPos)
{
  {
    CAutoLock cObjectLock(&m_GetTimeLock);
    m_MediaPos = MediaPos ;
    m_BaseTime = (REFERENCE_TIME)GetTickCount() * 10000 ; // m_pClock->GetTime(&m_BaseTime) ;
    m_LastTime=m_BaseTime ;
  }
//  LogDebug("SetMediaPos : %f %f",(float)MediaPos/10000,(float)m_LastTime/10000) ; 

// This is not really the right place, but this is the only method called by "MPmain" that could allow
// TsReader to "Pause" itself without deadlock issue.
// This is also here to allow compatibility with previous releases, avoiding a new callback from MP.

  if (m_bRenderingClockTooFast)
  {
    if (m_bPauseOnClockTooFast)
     [b][COLOR="Red"]{  
      m_bRenderingClockTooFast=false ;[/b][/COLOR]    //// Possible continious calculation and loging from Demux: Audio/Video to Render
      return ;                  // Do not re-enter ! /// maybe not so good because when a lot of logging entries will occur???
     [b][COLOR="Red"]}[/b][/COLOR]
     if (GetCurrentThreadId()!=m_MPmainThreadID) 
      return ;                  // Only MPmain can do that !
    if (((m_MediaPos/10000)-m_absSeekTime.Millisecs()) < 30*1000)
    {
      return ;                  
    }

    m_bPauseOnClockTooFast=true ;
    if (State() == State_Running)
    {
      IMediaControl * ptrMediaCtrl;
      if (SUCCEEDED(GetFilterGraph()->QueryInterface(IID_IMediaControl, (void**)&ptrMediaCtrl)))
      {
        LogDebug("Pause 200mS renderer clock to match provider/RTSP clock...") ; 
//       [b]ptrMediaCtrl->Pause() ;[/b]
//      [b]Sleep(200) ;[/b]
//        m_TestTime = GetTickCount() ;
//       [b]ptrMediaCtrl->Run() ;[/b]
        m_bRenderingClockTooFast=false ;
      }
      else
        LogDebug("Pause failed...") ; 
    }
//   [b]m_bPauseOnClockTooFast=false[/b] ; // no re-enter, dont need more than the first occured Log entries with Timestamp 
  }
}

First TSReader with all changes, and second TsReader without the Red marked changes, Thanks a lot.

When there is really a Problem with to fast Systemclocks, what can happen??? I`d expect first, LiveTV Streaming became continious Stuttering, further freezes or something else. But maybe it works well, so I`d like to test whats really
happens.



Thanks
Florian

 

[Owlsroost]

Please try the attached TsReader - it buffers more audio at the start (300ms instead of 200ms) - it should make it less likely to run out of audio data near the start.

Tony

 

[cfforce]

I've tried the patch, and noticed some faster zapping, but when i change from SD >> HD, the screen stays black.
(Attached the logs)
Same thing happens with the patch @ https://forum.team-mediaportal.com/...low-rtsp-startup-causes-eof-indication-96460/

But the nostopmod29 works fine: https://forum.team-mediaportal.com/...eze-15-30-helps-98842/index15.html#post793746

Using non-RTSP (UNC) to timeshift.

 

[jimbeam128]

AW: Stuttering on Live-TV - since 1.2

Hello again,

I also tested the patch (copy in Program Files folder and register). Same Issue... :-(