[Bug] Tvservice cpu usage increase problem while .ts playback fullscreen (1 Viewer)

[georgius]

What this has highlighted though is that there seems to be some excessive polling in TVHOME when no video is playing, nothing as dramatic as the corrected bug but there is an increase in cpu usage from 1-3% to 9-11% for tvservice; this maybe a necessary working within TVHOME and not a bug. (I have noticed this for some time in 1.1.3 and some previous releases, it was a problem some years ago and reduced with a fix by tourettes if I remember)

Probably I found reason why is in MP TV home screen higher CPU usage. The last update time is not updated when

1. card is not timeshifting (!Card.IsTimeShifting)
2. GUIGraphicsContext.InVmr9Render is TRUE

In that case are frequently called various methods (e.g. UpdateRecordingIndicator() or UpdateStateOfRecButton()) or accessed properties (e.g. Card.IsTimeShifting) which cause higher CPU usage. I also attached patch which fixed this problem in my environment.

 

[gibman]

thx.

added v4 of the patch.. which contains georgius+owlroost paches. In other words, all the work done.

although ... huge code smell found.

to make the code more robust in the process method of tvhome we can use the try-finally construction.
it will make sure that the update timer is always being updated regardless.
this will also prevent future bugs where a developer might forget to set the update timer when doing modifications to this method.
now we have done it for him.. once and for all

  public override void Process()
    {
      TimeSpan ts = DateTime.Now - _updateTimer;
      if (!Connected || _suspended || ts.TotalMilliseconds < 1000)
      {
        return;
      }

      try
      {
        UpdateRecordingIndicator();
        UpdateStateOfRecButton();

        if (!Card.IsTimeShifting)
        {
          UpdateProgressPercentageBar();
          // mantis #2218 : TV guide information in TV home screen does not update when program changes if TV is not playing           
          return;
        }

        // BAV, 02.03.08: a channel change should not be delayed by rendering.
        //                by moving thisthe 1 min delays in zapping should be fixed
        // Let the navigator zap channel if needed
        if (Navigator.CheckChannelChange())
        {
          UpdateGUIonPlaybackStateChange();
        }

        if (GUIGraphicsContext.InVmr9Render)
        {         
          return;
        }

        ShowCiMenu();

        doProcess();
      }
      finally
      {
        _updateTimer = DateTime.Now;
      }            
    }

 

[tourettes]

although ... huge code smell found.

to make the code more robust in the process method of tvhome we can use the try-finally construction.
it will make sure that the update timer is always being updated regardless.
this will also prevent future bugs where a developer might forget to set the update timer when doing modifications to this method.
now we have done it for him.. once and for all

TimeSpan ts = DateTime.Now - _updateTimer;
if (!Connected || _suspended || ts.TotalMilliseconds < 1000)
{
  return;
}

I would move even that block inside the try block - to be more future proof, since it is easier to add a new code that can throw outside the try block. Just to be more safe in the future

 

[gibman]

In this case we do NOT want to set the updatetimer since the timer is below the max interval of 1000 msec.
If we put this code block into the try-finally structure, then it will always set the update timer and then it will always exit and in turn perform nothing

/gibman

although ... huge code smell found.

to make the code more robust in the process method of tvhome we can use the try-finally construction.
it will make sure that the update timer is always being updated regardless.
this will also prevent future bugs where a developer might forget to set the update timer when doing modifications to this method.
now we have done it for him.. once and for all

TimeSpan ts = DateTime.Now - _updateTimer;
if (!Connected || _suspended || ts.TotalMilliseconds < 1000)
{
  return;
}

I would move even that block inside the try block - to be more future proof, since it is easier to add a new code that can throw outside the try block. Just to be more safe in the future

 

[georgius]

I tested gibman's patch in fullscreen and non fullscreen mode and CPU usage was low.

In this case we do NOT want to set the updatetimer since the timer is below the max interval of 1000 msec.
If we put this code block into the try-finally structure, then it will always set the update timer and then it will always exit and in turn perform nothing

I agree with you.

 

[tourettes]

In this case we do NOT want to set the updatetimer since the timer is below the max interval of 1000 msec.
If we put this code block into the try-finally structure, then it will always set the update timer and then it will always exit and in turn perform nothing

Ups, didn't look too closely the code Well, lets leave that small possibility for future throws to screw things up - we need some bugs in future as well

 

[gibman]

mantis:
0003667: tvservice cpu usage increases when client playbacks TV/rec. fullscreen. - MediaPortal Bugtracker

I guess this fix will be nice for multiple clients setup using a weaker cpu.

as we have:
multiple fullscreen clients => n'th time more cpu usage on tvserver.

/gibman

 

[cfforce]

Is there for v4 a binary available, got a new system here (server) based on AMD E350, with multiple tuners, want to test this out.

 

[SciDoctor]

Any chance of a compiled version of TvPlugin.dll with final mod applied for 1.2.0 Beta so that I can test.

Many thanks. back at 2pm Tuesday BST.

 

[offbyone]

I just tested Owlsroost's attached dll on my AMD E350 with a DigitalDevices DuoFlex in TvFullScreen watching SD unencrypted channel (Singleseat ofc):
MP 1.2 beta dll: MediaPortal 25% CPU | TvService 15% CPU
with patched dll: MediaPortal 21% CPU | TvService 3% CPU