Severe thumbnail problems

[Roger Larsson]

On Sunday 22 December 2002 18:51, Malte Starostik wrote:
> On Sunday 22 December 2002 12:50, Martijn Klingens wrote:
> > On Sunday 22 December 2002 11:37, Malte Starostik wrote:
> > Artsd has some safeguards against excessive CPU usage anyway. The main
> > problem as I see it from this thread is that there are more instances of
> > artsd. IIRC there should be only one, which is supposed to be reused for
> > subsequent tasks, so the CPU monitoring can also be done properly by this
> > one and only daemon. See also the earlier threads on artsd's realtime
> > priority btw.
> >
> > Since the thumbnail code fires up a few slaves at the same time I think
> > this is a race condition where no running artsd is detected and 10 slaves
> > are each given their own artsd instance. I don't know where the check for 
a
> > running artsd is done now, but most robust to me would probably be a 
single
> > entry point in e.g. klauncher which makes sure no second artsd is started
> > (or a kded module). Good enough for this case, and a lot easier to write,
> > but not avoid races between different applications, is to have the check 
in
> > the thumbnail generating code, just before spawning the slave. Downside of
> > this is that the thumb code explicitly needs to know whether a slave is
> > arts-using or not.
> 
> As mentioned before, the A/V previews do *not* use the kio_thumbnail. 
> libkonq/konq_sound.cc is responsible for them and there is only one instance 
> of konq_sound at a time per konqueror view. And when the view loses focus, 
> this instance stops. The only chance of a race caused here is if you have 
> multiple views and move around with the pointer very fast between them, from 
> one A/V file to another.
> 
> -Malte
> 

I think the problem is icon thumbnail creation.

When a folder that has lots of .mpg:s but no thumbnails yet is
entered. It looks like one artsd (child?) is spawned per icon to
create (i.e. one artsd thread/process per mpeg)

My guess is that it does not stop when the first frame is retrieved
but that those will continue to play the full file. (my interpretation,
it might be that getting the first frame requires so much data read
that it does not matter)

This is not good when it is done on many large files at once.
What will happen is that they all will stall because of seeks on disk.

I do run with arts enabled, do also see:
http://bugs.kde.org/show_bug.cgi?id=51277

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden