vdr slowness when browsing channels

  Hi,

Guy Roussin wrote:

> I notice that vdr is slow when i try to quickly browse 
> channels. it eats around 18-20% of the cpu (atlon1200) when
> i hold left or right key when browsing channels (vdr 1.3.27 
> vanilla - classic skin) .
> With text2skin (1.0) and Enigma, it eats around 40-50% of
> the cpu and browsing channels is very very slow ...
> Note: cat channels.conf | wc -l  --> 2600 lines

Just give the attached patch a try and report the effect.

The problem seems to be, that for scrolling one line, all 2600 channels 
are sent to plugins. The patch changes this behaviour to just send those 
channels to plugins that will be shown on screen by VDR.

Other people say that this change is not good as some plugins are able 
to display more lines than VDR does and therefore they nolonger receive 
the necessary data.

I'd vote for a change in API where VDR just announces the lines it will 
display on screen and any plugin that needs more lines than that should 
be able to pull this data on its own.

Bye.
  

Reinhard Nissl wrote:
> Hi,
> 
> Guy Roussin wrote:
> 
>> I notice that vdr is slow when i try to quickly browse channels. it 
>> eats around 18-20% of the cpu (atlon1200) when
>> i hold left or right key when browsing channels (vdr 1.3.27 vanilla - 
>> classic skin) .
>> With text2skin (1.0) and Enigma, it eats around 40-50% of
>> the cpu and browsing channels is very very slow ...
>> Note: cat channels.conf | wc -l  --> 2600 lines
> 
> 
> Just give the attached patch a try and report the effect.
> 
> The problem seems to be, that for scrolling one line, all 2600 channels 
> are sent to plugins. The patch changes this behaviour to just send those 
> channels to plugins that will be shown on screen by VDR.

These are only sent to plugins that actually implement a cStatus object.
Why would text2skin need a cStatus?

Klaus
  

Hi,

Klaus Schmidinger wrote:

>>> I notice that vdr is slow when i try to quickly browse channels. it 
>>> eats around 18-20% of the cpu (atlon1200) when
>>> i hold left or right key when browsing channels (vdr 1.3.27 vanilla - 
>>> classic skin) .
>>> With text2skin (1.0) and Enigma, it eats around 40-50% of
>>> the cpu and browsing channels is very very slow ...
>>> Note: cat channels.conf | wc -l  --> 2600 lines
>>
>> Just give the attached patch a try and report the effect.
>>
>> The problem seems to be, that for scrolling one line, all 2600 
>> channels are sent to plugins. The patch changes this behaviour to just 
>> send those channels to plugins that will be shown on screen by VDR.
> 
> These are only sent to plugins that actually implement a cStatus object.
> Why would text2skin need a cStatus?

 From the sources:
.
.
class cText2SkinStatus: public cStatus {
.
.

But it doesn't implement OsdItem(), so maybe my assumption was wrong.

Maybe it would make sense to have a second list of status monitors which 
contains all those cStatus objects which implement OsdItem() and to skip 
the loop completely if noone is interested this information.

What do you think about that, Klaus?
Shall I create a patch for this?

Bye.
  

Klaus Schmidinger wrote:

> 
> These are only sent to plugins that actually implement a cStatus object.
> Why would text2skin need a cStatus?

And why would a cStatus object need to be resent all objects on the 
display even if none has changed?
Besides, just calling cStatus::MsgOsdItem should have some overhead.

Bye
  

Reinhard Nissl wrote:
> Hi,
> 
> Klaus Schmidinger wrote:
> 
>>>> I notice that vdr is slow when i try to quickly browse channels. it 
>>>> eats around 18-20% of the cpu (atlon1200) when
>>>> i hold left or right key when browsing channels (vdr 1.3.27 vanilla 
>>>> - classic skin) .
>>>> With text2skin (1.0) and Enigma, it eats around 40-50% of
>>>> the cpu and browsing channels is very very slow ...
>>>> Note: cat channels.conf | wc -l  --> 2600 lines
>>>
>>>
>>> Just give the attached patch a try and report the effect.
>>>
>>> The problem seems to be, that for scrolling one line, all 2600 
>>> channels are sent to plugins. The patch changes this behaviour to 
>>> just send those channels to plugins that will be shown on screen by VDR.
>>
>>
>> These are only sent to plugins that actually implement a cStatus object.
>> Why would text2skin need a cStatus?
> 
> 
>  From the sources:
> .
> .
> class cText2SkinStatus: public cStatus {
> .
> .
> 
> But it doesn't implement OsdItem(), so maybe my assumption was wrong.
> 
> Maybe it would make sense to have a second list of status monitors which 
> contains all those cStatus objects which implement OsdItem() and to skip 
> the loop completely if noone is interested this information.
> 
> What do you think about that, Klaus?
> Shall I create a patch for this?

I don't think so.
Besides, OsdItem() and OsdCurrentItem() don't really play that well
together, anyway. As it is now, a cStatus object gets the full list
of all items when cOsdMenu::Display() is called, but the current
item is only referred to by its text, no index is given.
So I think this needs some more thought.

But let's first find out whether this is really the problem here.
On my system I also have a cStatus object in the RCU remote control,
and it also doesn't implement OsdItem(). Paging through the channel
list is not slow at all.

@Guy: please comment out the lines

        for (cOsdItem *item = First(); item; item = Next(item))
            cStatus::MsgOsdItem(item->Text(), ni++);

in cOsdMenu::Display() (osdbase.c) and let us know whether this
makes any change.

Klaus
  

Klaus Schmidinger wrote:
> Reinhard Nissl wrote:
> > Hi,
> > 
> > Guy Roussin wrote:
> > 
> >> I notice that vdr is slow when i try to quickly browse channels. it 
> >> eats around 18-20% of the cpu (atlon1200) when
> >> i hold left or right key when browsing channels (vdr 1.3.27 vanilla - 
> >> classic skin) .
> >> With text2skin (1.0) and Enigma, it eats around 40-50% of
> >> the cpu and browsing channels is very very slow ...
> >> Note: cat channels.conf | wc -l  --> 2600 lines
> ...
> > The problem seems to be, that for scrolling one line, all 2600 channels 
> > are sent to plugins. The patch changes this behaviour to just send those 
> > channels to plugins that will be shown on screen by VDR.
> 
> These are only sent to plugins that actually implement a cStatus object.

Iirc that was a real performance issue on my old 200 MHz machine. :-(

Two possible solutions:
- The list of items should only be sent when the menu opens, not for
  each cursor movement.
- Only items at cursor_pos-N ... cursor_pos+N should be sent through
  cStatus. N = 50 or 100 should be sufficient.

Oliver
  

Klaus Schmidinger wrote:
> Besides, OsdItem() and OsdCurrentItem() don't really play that well
> together, anyway. As it is now, a cStatus object gets the full list
> of all items when cOsdMenu::Display() is called, but the current
> item is only referred to by its text, no index is given.
> So I think this needs some more thought.

Yes, that's not optimal. At the moment a plugin has to do a string
search in the OsdItem list to find the index of OsdCurrentItem.
Works most of the time, but fails if there are two similar OsdItems,
for example in some setup menus.

It would be great, if the current index could be queried somehow or
would be passed as a parameter through OsdCurrentItem().

Oliver
  

Klaus Schmidinger wrote:

> @Guy: please comment out the lines
> 
>        for (cOsdItem *item = First(); item; item = Next(item))
>            cStatus::MsgOsdItem(item->Text(), ni++);

didn't make a big difference, exactly nothing with the dxr3 plugin (cpu 
use around 100%, probably most of the cpu is used by the dxr3 osd 
routines) and around 5-7% with the xine plugin (cpu use something less 
that 60% without the cStatus::MsgOsdItem, around 65% with).
I'm using a duron at 1200Mhz, probably the difference would be bigger 
with a less powerful cpu.

Bye
  

Luca Olivetti wrote:
> Klaus Schmidinger wrote:
> 
>> @Guy: please comment out the lines
>>
>>        for (cOsdItem *item = First(); item; item = Next(item))
>>            cStatus::MsgOsdItem(item->Text(), ni++);
> 
> 
> didn't make a big difference, exactly nothing with the dxr3 plugin (cpu 
> use around 100%, probably most of the cpu is used by the dxr3 osd 
> routines) and around 5-7% with the xine plugin (cpu use something less 
> that 60% without the cStatus::MsgOsdItem, around 65% with).
> I'm using a duron at 1200Mhz, probably the difference would be bigger 
> with a less powerful cpu.

So the cStatus thing isn't what's causing this.

Well, must be something else in text2skin then.
After all, this is a rather complex plugin that does a lot
of "eye candy" stuff - apparently beauty comes at a price... ;-)

Klaus
  

Klaus Schmidinger wrote:

>> didn't make a big difference, exactly nothing with the dxr3 plugin 
>> (cpu use around 100%, probably most of the cpu is used by the dxr3 osd 
>> routines) and around 5-7% with the xine plugin (cpu use something less 
>> that 60% without the cStatus::MsgOsdItem, around 65% with).
>> I'm using a duron at 1200Mhz, probably the difference would be bigger 
>> with a less powerful cpu.
> 
> 
> So the cStatus thing isn't what's causing this.
> 
> Well, must be something else in text2skin then.
> After all, this is a rather complex plugin that does a lot
> of "eye candy" stuff - apparently beauty comes at a price... ;-)

Note that I did my tests with ST:TNG just to keep text2skin out of the 
picture ;-) but of course you're right: text2skin takes a noticeable hit 
on the cpu.
Anyway, even with enigma channel scrolling isn't slow with the xine 
plugin[*] but it is with the dxr3 (due to 100% cpu usage), so definitely 
cStatus isn't the cause (and I have ~4500 lines in channel.conf).
Since Guy's processor is comparable to mine (heck, his is an athlon, 
mine is a duron), there should be something else.
[*] with xine running on a different machine, probably running xine and 
vdr on the same machine would use too much cpu too.

Bye
  

Hi,

> @Guy: please comment out the lines
> 
>        for (cOsdItem *item = First(); item; item = Next(item))
>            cStatus::MsgOsdItem(item->Text(), ni++);
> 
> in cOsdMenu::Display() (osdbase.c) and let us know whether this
> makes any change.
No, that does not change anything. Around 20% of the cpu for vdr process
when browsing channels with left or right keys of my remote control.

I test this patch with vdr 1.3.27 and 1.3.28, same results.
I test with left and right keys (keyboard) and now the scroll is even
faster but it take around 35-40% of the cpu (with or without the patch).

With text2skin and Enigma again, i notice no changes with this patch :
40-50% of the cpu with remote and even 65-70% with the keyboard.

I note that browsing with the keyboard is very fast and no jerks as
with the remote control. It seems that some press on the remote control
are lost by vdr.


Thanks,

Guy