Gentoo Archives: gentoo-user

From: Wols Lists <antlists@××××××××××××.uk>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] KDE plasmashell and wallpapers.
Date: Tue, 24 Dec 2019 18:15:25
Message-Id: 5E0255B1.5000909@youngman.org.uk
In Reply to: Re: [gentoo-user] KDE plasmashell and wallpapers. by Mick
1 On 24/12/19 09:53, Mick wrote:
2 > On Tuesday, 24 December 2019 06:40:13 GMT Dale wrote:
3 >> Howdy,
4 >>
5 >> It seems plasmashell and wallpapers for the desktop has a problem. I'm
6 >> not sure if it is just me or if it could affect others. Either way, I
7 >> have no idea how to fix it. I have a LOT of wallpapers that I've
8 >> downloaded/collected over the years. Some are NASA pics of Mars, stars,
9 >> galaxies and a whole lot of others that I've accumulated over the last
10 >> 15 years or so. According to Dolphin and the properties box, it's well
11 >> over 100,000 of them.
12 >
13 > WOW! A rather large number I would think.
14 >
15 No it's not, I would think. Dunno how many I've accumulated, but I've
16 taken a fair few pictures of my own over the years, downloaded loads,
17 scanned lots of my old stuff ... it all adds up much faster than you
18 think ...
19 >
20 <snip>
21 >>
22 >> Problem. When I have it set to the main directory and I login to KDE,
23 >> plasmashell goes nuts. It hogs up a full CPU core and never stops.
24 >> It's not exactly memory friendly either. The little panel thingy at the
25 >> bottom, the thing with the clock and the pager etc, locks up tight. The
26 >> clock doesn't change, you can't select anything with it or anything
27 >> else. Just for giggles, I left it for half a hour or so hoping it would
28 >> finish whatever it was doing but it never did. Killing plasmashell and
29 >> restarting results in the same problem. Once it does that, I have to
30 >> downgrade to a earlier version of plasma. While fiddling with it today,
31 >> I had the idea of manually restarting plasmashell and letting it show on
32 >> the screen what it was doing. Since the panel thingy won't work,
33 >> neither does the clipboard so no copy and paste of the actual error
34 >> itself. What it showed me tho was that the wallpapers was the problem.
35 >> It said something about bad metadata for each and every wallpaper image
36 >> I have stored. I can't recall the error exactly but may can reproduce
37 >> it later.
38 >
39 If it's what's locking up my SUSE box, you don't need that many
40 pictures! Certainly sounds like it - "load" goes through the roof, and
41 system response goes through the floor. It eventually sorts itself out
42 (usually), but it's a bugger.
43
44 > Take a pic of it so you have a more precise idea what it reports and google
45 > for ideas on what may be causing it. If you're on a console use tee to
46 > redirect the output to a file, or use gpm to select some text off the screen
47 > and paste it in a file.
48 >
49
50
51
52 >
53 > I have found the file indexer occasionally chews up CPU non-stop. I think I
54 > disabled it at some point but in any case I have not noticed it chewing up CPU
55 > since. Could it be the file indexer now needs to re-index all your images and
56 > it falls over itself due to the number and directory depth?
57 >
58
59
60 >
61 > Is there a difference in the metadata of these few images compared with the
62 > rest in the whole directory?
63 >
64 That would be a bugger - I think different scanners, different cameras,
65 different whatevers all seem to interpret the jpeg spec slightly
66 differently, with the result that any program that tries to strictly
67 enforce its interpretation is doomed to reject most pictures as
68 "invalid" :-( It's a nightmare the times I get one program objecting to
69 another program's output ... and I don't actually use these programs
70 enough to get a handle on what's going on.
71
72 >
73 >> Setting it to the whole
74 >> directory after that tho, does the same as above. So doing a sort of
75 >> reset doesn't help. Heck, at one point, I cleaned up the living room,
76 >> took out the trash and did some other stuff while it was banging away
77 >> with a core on my CPU. Thing never did finish.
78 >>
79 >> Anyone even know where to start with this? I've got it narrowed down to
80 >> it being a issue with wallpapers. I just don't know where to go from
81 >> here. Is it supposed to do that for some reason and I'm the only one
82 >> with a HUGE collection? Surely not.
83 >>
84 >> Thanks.
85 >>
86 >> Dale
87 >>
88 >> :-) :-)
89 >
90 > Some ideas in no particular order:
91 >
92 > Compare the metadata of an image which works without crashing and one that
93 > causes a crash, with exif or less. If there is no discernible difference it
94 > may be the problem is not with the metadata, but with Plasma being able to
95 > parse all these files and their metadata.
96 >
97 > Gradually add images to find a number at which the problem occurs and back off
98 > from there. Not a solution, but a workaround.
99 >
100 > Another workaround, restructure the fs to have fewer layers, but keep the same
101 > large number of images to see if it process them without a crash.
102 >
103 > Do you really all 100,000 images? Is it worth keeping all of them, or is it
104 > perhaps time for some house keeping?
105 >
106 > Wait for new Plasam version to come out and perhaps report a bug if one is not
107 > yet posted.
108 >
109 Shades of when - was it akonadi? - the file indexer started at boot and
110 killed system response so badly that it was taking a lot of systems more
111 than A DAY to log in the shell!!! I got bitten by that, and the response
112 of the devs seemed to be "we're not interested unless you're interested
113 in helping us debug it" :-(
114
115 Sorry, but I'm not interested in helping debug a problem that renders my
116 system so badly incapacitated that I can't even get a response out of
117 it! I was forced to ditch KDE just to get a usable system ...
118
119 (That said, I'd be delighted if this is the problem and we get a cure
120 for our broken boot ...)
121
122 Cheers,
123 Wol