On 24/12/19 09:53, Mick wrote: > 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. > No it's not, I would think. Dunno how many I've accumulated, but I've taken a fair few pictures of my own over the years, downloaded loads, scanned lots of my old stuff ... it all adds up much faster than you think ... > <snip> >> >> 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. > If it's what's locking up my SUSE box, you don't need that many pictures! Certainly sounds like it - "load" goes through the roof, and system response goes through the floor. It eventually sorts itself out (usually), but it's a bugger.
> 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 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 there a difference in the metadata of these few images compared with the > rest in the whole directory? > That would be a bugger - I think different scanners, different cameras, different whatevers all seem to interpret the jpeg spec slightly differently, with the result that any program that tries to strictly enforce its interpretation is doomed to reject most pictures as "invalid" :-( It's a nightmare the times I get one program objecting to another program's output ... and I don't actually use these programs enough to get a handle on what's going on. > >> 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. > Shades of when - was it akonadi? - the file indexer started at boot and killed system response so badly that it was taking a lot of systems more than A DAY to log in the shell!!! I got bitten by that, and the response of the devs seemed to be "we're not interested unless you're interested in helping us debug it" :-( Sorry, but I'm not interested in helping debug a problem that renders my system so badly incapacitated that I can't even get a response out of it! I was forced to ditch KDE just to get a usable system ... (That said, I'd be delighted if this is the problem and we get a cure for our broken boot ...) Cheers, Wol
