Re: [gentoo-user] KDE plasmashell and wallpapers.

[Mick]

On Tuesday, 24 December 2019 06:40:13 GMT Dale wrote:
> Howdy,
>
> It seems plasmashell and wallpapers for the desktop has a problem.  I'm
> not sure if it is just me or if it could affect others.  Either way, I
> have no idea how to fix it.  I have a LOT of wallpapers that I've
> downloaded/collected over the years.  Some are NASA pics of Mars, stars,
> galaxies and a whole lot of others that I've accumulated over the last
> 15 years or so.  According to Dolphin and the properties box, it's well
> over 100,000 of them.

WOW!  A rather large number I would think.


> I have them all in a directory named, wait for
> it, wallpapers.  Under that they are sorted in directories by what they
> are, where they come from or whatever.  I try not to go to deep but it
> does pick up at least two or three levels deep.  I've had it set that
> way for ages and it has always worked with the only problem being it
> picking them at random.  Some are intended to be like a slideshow.
> Anyway, they added the option of doing them in different orders
> including a-z, which is nice.  It will be nicer if I can get it to work
> now.  ;-)
>
> Problem.  When I have it set to the main directory and I login to KDE,
> plasmashell goes nuts.  It hogs up a full CPU core and never stops.
> It's not exactly memory friendly either.  The little panel thingy at the
> bottom, the thing with the clock and the pager etc, locks up tight.  The
> clock doesn't change, you can't select anything with it or anything
> else.  Just for giggles, I left it for half a hour or so hoping it would
> finish whatever it was doing but it never did.  Killing plasmashell and
> restarting results in the same problem.  Once it does that, I have to
> downgrade to a earlier version of plasma.  While fiddling with it today,
> I had the idea of manually restarting plasmashell and letting it show on
> the screen what it was doing.  Since the panel thingy won't work,
> neither does the clipboard so no copy and paste of the actual error
> itself.  What it showed me tho was that the wallpapers was the problem.
> It said something about bad metadata for each and every wallpaper image
> I have stored.  I can't recall the error exactly but may can reproduce
> it later.

Take a pic of it so you have a more precise idea what it reports and google 
for ideas on what may be causing it.  If you're on a console use tee to 
redirect the output to a file, or use gpm to select some text off the screen 
and paste it in a file.


> I suspect when the option to have them random or in order was
> added, something changed in the way it looks at the directory.  Thing
> is, I have no idea how to make this work like it should with all of them
> enabled.

I have found the file indexer occasionally chews up CPU non-stop.  I think I 
disabled it at some point but in any case I have not noticed it chewing up CPU 
since.  Could it be the file indexer now needs to re-index all your images and 
it falls over itself due to the number and directory depth?

Is possible to drop into a console or ssh into this PC when it's hanging to 
see what process(es) are taking up resources in real time?


> My temporary solution, I pointed it to a small directory that only has a
> couple dozen images in it.  That seems to work.

Is there a difference in the metadata of these few images compared with the 
rest in the whole directory?


> Setting it to the whole
> directory after that tho, does the same as above.  So doing a sort of
> reset doesn't help.  Heck, at one point, I cleaned up the living room,
> took out the trash and did some other stuff while it was banging away
> with a core on my CPU.  Thing never did finish.
>
> Anyone even know where to start with this?  I've got it narrowed down to
> it being a issue with wallpapers.  I just don't know where to go from
> here.  Is it supposed to do that for some reason and I'm the only one
> with a HUGE collection?  Surely not.
>
> Thanks.
>
> Dale
>
> :-)  :-)

Some ideas in no particular order:

Compare the metadata of an image which works without crashing and one that 
causes a crash, with exif or less.  If there is no discernible difference it 
may be the problem is not with the metadata, but with Plasma being able to 
parse all these files and their metadata.

Gradually add images to find a number at which the problem occurs and back off 
from there.  Not a solution, but a workaround.

Another workaround, restructure the fs to have fewer layers, but keep the same 
large number of images to see if it process them without a crash.

Do you really all 100,000 images?  Is it worth keeping all of them, or is it 
perhaps time for some house keeping?

Wait for new Plasam version to come out and perhaps report a bug if one is not 
yet posted.
-- 
Regards,

Mick