On Sonntag 15 Mai 2005 13:38, Klaus Schmidinger wrote:

...

Today I found out that it's a syslog message from osd.c "too many different colors used in palette", which arises a several thousand times (I've seen a "last message repeated 119327 times").

While the real reason may be found in the text2skin plugin, I think this syslog message should be somehow suppressed if repeated very often.

Any ideas?

Shouldn't syslog suppress consecutive same messages automatically?

Well, it does: last message repeated 119327 times But that suppression takes CPU cycles.

Am Sonntag 15 Mai 2005 13:38 schrieb Klaus Schmidinger:

Michael Reinelt wrote:

...

Hi there,

I recently installed the text2skin plugin and the DeepBlue skin with VDR-1.3.24. Everything works fine (and look s cool!), but I noticed that from time to time something eats up all my CPU time (I'm on a diskless EPIA-M6000, where CPU cycles are valuably), especially in the "Channels" list. CPU usage goes up to 100% for one or two seconds (I can observe this on my built-in LCD display running lcd4linux), afterwards everything is fine again. The problem is that during this period the remote control is somewhat jerky...

Today I found out that it's a syslog message from osd.c "too many different colors used in palette", which arises a several thousand times (I've seen a "last message repeated 119327 times").

While the real reason may be found in the text2skin plugin, I think this syslog message should be somehow suppressed if repeated very often.

Any ideas?

Shouldn't syslog suppress consecutive same messages automatically?

Klaus

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Not every syslog daemon does this. I had the same problem, I removed the dsyslog line in osd.c and now it works.

S.

Am Sonntag 15 Mai 2005 15:40 schrieb Klaus Schmidinger:

Sebastian Frei wrote:

...

Am Sonntag 15 Mai 2005 13:38 schrieb Klaus Schmidinger:

...

Michael Reinelt wrote:

...

Hi there,

I recently installed the text2skin plugin and the DeepBlue skin with VDR-1.3.24. Everything works fine (and look s cool!), but I noticed that from time to time something eats up all my CPU time (I'm on a diskless EPIA-M6000, where CPU cycles are valuably), especially in the "Channels" list. CPU usage goes up to 100% for one or two seconds (I can observe this on my built-in LCD display running lcd4linux), afterwards everything is fine again. The problem is that during this period the remote control is somewhat jerky...

Today I found out that it's a syslog message from osd.c "too many different colors used in palette", which arises a several thousand times (I've seen a "last message repeated 119327 times").

While the real reason may be found in the text2skin plugin, I think this syslog message should be somehow suppressed if repeated very often.

Any ideas?

Shouldn't syslog suppress consecutive same messages automatically?

Klaus

Not every syslog daemon does this. I had the same problem, I removed the dsyslog line in osd.c and now it works.

Which is only curing the symptoms... ;-)

Sure, but I don't see any errors in the osd, it looks very good.

S.

Hi there,

Finally I think I found the bug which eats my CPU time.

It's a bit complicated, and I'm not sure how this is fixed best. The bug is not within VDR, the hundred thousands calls dsyslog() were just a symtom, not the real cause.

Let me explain:

As I already suspected, it's related to the channel logos of the DeepBlue skin. I added some debug statements to the file bitmap.c from the text2skin plugin, and found out that the skin renders all channel logos with a size of 506x616 pixels, which is *far* too big, leads to an absolutely useless scaling of the image, and calls DrawPixel() and therefore cPalette::Index() about 300.000 times, requesting far too much colors, and therefore triggered the dsyslog() call.

But why the hell 506x616 pixels? Well, it took me some time to understand this one: The reason is not the rendering of the bitmap (which is *never* used!), but the call to cText2SkinBitmap::Available(), which is used by the file() expression from the XML skin processor.

Available() simply tries to load the bitmap and returns !NULL if successful. It is called with the size of the object, which seems to be unknown in the <block condition="file(...)"> case, using the whole size of the OSD.

All this takes *a lot of* useless CPU time! I did some quick&dirty hacks, the results are impressive! No more CPU peaks in the "Channels" menu, and much faster!

Now, how can this be fixed?

First, we could change the cText2SkinBitmap::Available() function: cText2SkinBitmap *bmp = Load(Filename, Alpha, height, width, colors, true); to cText2SkinBitmap *bmp = Load(Filename, Alpha, 0, 0, colors, true);

Second, we could change the cxFunction::FunFile() from xml/function.c and remove the mObject->Size().* parameters, setting them to zero.

But, I'd prefer another solution: The Reference doc from the Text2Skin plugin reads:

3.10 file

Returns the parameter, if the file exists in the skin directory.

It says "if the file exists", but in fact it checks if it's a valid bitmap! Maybe someone wants to check for a non-bitmap file????

I's suggest replacing the call to cText2SkinBitmap::Available() with a simple call to stat(), checking for file existance, and nothing more.

Any comments?

bye, Michael