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

[Tako Schotanus]

Kenneth Aafløy wrote:

>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?
>  
>
You're now responding to two people at the same time :-)
I agree with you that this is not enough.

>  
>
>>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.
>  
>
True, what I meant with "should" is, that it "should have been 
implemented because the options to enable/disable it exist".

>  
>
>>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 "pull lcd info from backend" part I don't understand, why do you 
think the backend is involved here? It shouldn't be if I understand and 
remember correctly. It's just a pointer to the local lcd device on the 
frontend as far as I know. And the info about the currently playing 
program was already available so calculating the position should not 
take any (extra) time.

That doesn't mean you are right in limiting the number of updates. I 
even think you haven't limited it enough because how much can the 
progress bar change in 1/4 of a second anyway? So as far as I'm 
concerned you can lower the frequency to once a second or even less.

>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.
>  
>
Right.

>Cheers,
>Kenneth
>
>  
>
-Tako