1 |
On Tuesday, December 24, 2019 10:53:13 AM CET 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 |
> > I have them all in a directory named, wait for |
16 |
> > it, wallpapers. Under that they are sorted in directories by what they |
17 |
> > are, where they come from or whatever. I try not to go to deep but it |
18 |
> > does pick up at least two or three levels deep. I've had it set that |
19 |
> > way for ages and it has always worked with the only problem being it |
20 |
> > picking them at random. Some are intended to be like a slideshow. |
21 |
> > Anyway, they added the option of doing them in different orders |
22 |
> > including a-z, which is nice. It will be nicer if I can get it to work |
23 |
> > now. ;-) |
24 |
> > |
25 |
> > Problem. When I have it set to the main directory and I login to KDE, |
26 |
> > plasmashell goes nuts. It hogs up a full CPU core and never stops. |
27 |
> > It's not exactly memory friendly either. The little panel thingy at the |
28 |
> > bottom, the thing with the clock and the pager etc, locks up tight. The |
29 |
> > clock doesn't change, you can't select anything with it or anything |
30 |
> > else. Just for giggles, I left it for half a hour or so hoping it would |
31 |
> > finish whatever it was doing but it never did. Killing plasmashell and |
32 |
> > restarting results in the same problem. Once it does that, I have to |
33 |
> > downgrade to a earlier version of plasma. While fiddling with it today, |
34 |
> > I had the idea of manually restarting plasmashell and letting it show on |
35 |
> > the screen what it was doing. Since the panel thingy won't work, |
36 |
> > neither does the clipboard so no copy and paste of the actual error |
37 |
> > itself. What it showed me tho was that the wallpapers was the problem. |
38 |
> > It said something about bad metadata for each and every wallpaper image |
39 |
> > I have stored. I can't recall the error exactly but may can reproduce |
40 |
> > it later. |
41 |
> |
42 |
> Take a pic of it so you have a more precise idea what it reports and google |
43 |
> for ideas on what may be causing it. If you're on a console use tee to |
44 |
> redirect the output to a file, or use gpm to select some text off the screen |
45 |
> and paste it in a file. |
46 |
> |
47 |
> > I suspect when the option to have them random or in order was |
48 |
> > added, something changed in the way it looks at the directory. Thing |
49 |
> > is, I have no idea how to make this work like it should with all of them |
50 |
> > enabled. |
51 |
> |
52 |
> I have found the file indexer occasionally chews up CPU non-stop. I think I |
53 |
> disabled it at some point but in any case I have not noticed it chewing up |
54 |
> CPU since. Could it be the file indexer now needs to re-index all your |
55 |
> images and it falls over itself due to the number and directory depth? |
56 |
> |
57 |
> Is possible to drop into a console or ssh into this PC when it's hanging to |
58 |
> see what process(es) are taking up resources in real time? |
59 |
> |
60 |
> > My temporary solution, I pointed it to a small directory that only has a |
61 |
> > couple dozen images in it. That seems to work. |
62 |
> |
63 |
> Is there a difference in the metadata of these few images compared with the |
64 |
> rest in the whole directory? |
65 |
> |
66 |
> > Setting it to the whole |
67 |
> > directory after that tho, does the same as above. So doing a sort of |
68 |
> > reset doesn't help. Heck, at one point, I cleaned up the living room, |
69 |
> > took out the trash and did some other stuff while it was banging away |
70 |
> > with a core on my CPU. Thing never did finish. |
71 |
> > |
72 |
> > Anyone even know where to start with this? I've got it narrowed down to |
73 |
> > it being a issue with wallpapers. I just don't know where to go from |
74 |
> > here. Is it supposed to do that for some reason and I'm the only one |
75 |
> > with a HUGE collection? Surely not. |
76 |
> > |
77 |
> > Thanks. |
78 |
> > |
79 |
> > Dale |
80 |
> > |
81 |
> > :-) :-) |
82 |
> |
83 |
> Some ideas in no particular order: |
84 |
> |
85 |
> Compare the metadata of an image which works without crashing and one that |
86 |
> causes a crash, with exif or less. If there is no discernible difference it |
87 |
> may be the problem is not with the metadata, but with Plasma being able to |
88 |
> parse all these files and their metadata. |
89 |
> |
90 |
> Gradually add images to find a number at which the problem occurs and back |
91 |
> off from there. Not a solution, but a workaround. |
92 |
> |
93 |
> Another workaround, restructure the fs to have fewer layers, but keep the |
94 |
> same large number of images to see if it process them without a crash. |
95 |
> |
96 |
> Do you really all 100,000 images? Is it worth keeping all of them, or is it |
97 |
> perhaps time for some house keeping? |
98 |
> |
99 |
> Wait for new Plasam version to come out and perhaps report a bug if one is |
100 |
> not yet posted. |
101 |
|
102 |
Or run the following: |
103 |
find ./ -iname "*" -type f -exec file {} \; > /tmp/file.txt |
104 |
|
105 |
from inside the Wallpaper-folder and check the output (see file /tmp/file.txt) |
106 |
for anything obvious. |
107 |
|
108 |
You will have a long line per file, so using "grep -v " to filter out known |
109 |
good results might help in finding the problem file(s) |
110 |
|
111 |
-- |
112 |
Joost |