[mythtv] [PATCH] Limit the updates for nonexisting LCD

[Kenneth Aafløy]

On Thursday 07 October 2004 14:15, Tako Schotanus wrote:
> Dan Morphis wrote:
> >On Thu, 7 Oct 2004 01:34:37 +0200, Kenneth Aafløy
> >
> ><lists at kenneth.aafloy.net> wrote:
> >>Hi,
> >>
> >>I've attached a patch which limits the number of updates my lcd (that
> >> does not exist) receives to max 4/s. This was really flodding the
> >> traffic between
> >
> >If the LCD doesn't exist, then why not update your settings.pro file
> >and comment out the LCD stuff and recompile?

That approach would not work, because then it still would be broken for those
that really use the LCD..also the code in question is not covered by the LCD 
compile time configurable, did you read the patch and sorrounding code?

> He could do that but that doesn't change the fact that it should work,
> maybe not with a hasLCD() function but using the frontend settings where
> you can decide which info to show on the display. You should at least be
> able to disable the LCD by unchecking all those items.

It still won't disable the code in question.

> Strange thing is that I wrote most of that code and I thought that when
> Isaac checked it in he had changed it to make it update a lot less
> often, my original code would update it every second. Obviously I was
> wrong.

The original loop goes something like this:

while (runMainLoop)
{
 - if queued, handle state change
 - sleep 1/1000s
 - if recording info is queued, fetch it
 - if playback, process any queued keys
 - if playback and player stopped, change state
 - if playback about to exit, handle exiting playback
 - if ++updatecheck >= 20
  - update osd
  - reset updatecheck
 - if a channel is queued and the osd is avail, commit it
 - check if it's 60s since last time
  - show lcd info
  - reset timer
 - pull lcd info from backend
 - set channel progress on the lcd
}

So essentially this code is not only flodding the backend, but it's 
essentially also blocking user interaction.

The updates could abviously potentially reach 1000 times per second, however 
it will not ever reach this amount, both because the usleep will certainly 
sleep more than a 1/1000s on most architechtures, but it will always strive 
for the most updates possible.

The backend only has a few threads (5 iirc) to do processing for the client 
sockets, so it's bound to be busy most of the time. Imagine this with a few 
clients connected to a backend at a time, or even worse, if the thread 
limitations was somehow solved, horrible.

Cheers,
Kenneth