Bug 371455 - Slide show wallpaper massively slows down login when many images are configured
Summary: Slide show wallpaper massively slows down login when many images are configured
Status: CLOSED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Image Wallpaper (show other bugs)
Version: 5.17.4
Platform: Arch Linux Linux
: HI major
Target Milestone: 1.0
Assignee: Marco Martin
URL:
Keywords: efficiency, regression
: 395972 413069 413934 414897 415119 426879 431256 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-10-21 19:03 UTC by kde
Modified: 2023-07-26 17:55 UTC (History)
26 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Desktop will not be frooze while a large amount of images presented when in slidemode (1.88 KB, patch)
2020-01-22 16:08 UTC, Yuking
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kde 2016-10-21 19:03:06 UTC
I have a quite slow NAS with several thousand images on it which I use as a source for a slide show wallpaper (5 mins between one image and the next).

When I log in to my account, I get the KDE logo and the spinner, which freezes after some time. After waiting for several minutes, the launch bar shows up and I can start using my account. There is still no background image (black screen).

Not sure right now if an image would show up after some time by itself; it does if I right-click on the background, select "next background image" (translated back from German), and wait another few minutes.

Reproducible: Always

Steps to Reproduce:
1. Use a slow source with many thousand images in hundreds of directories as wallpaper slide show.
2. Log in.

Actual Results:  
Login takes an eternity.

Expected Results:  
Launch bar and desktop without wallpaper image shows up right away. I can start working. Once the directory scan has completed, and the first image has been loaded, wallpaper images start to show.
Comment 1 kde 2016-10-21 19:10:22 UTC
Just to mention that: When I use a fixed wallpaper from the KDE collection, login is as quick as expected.
Comment 2 kde 2016-10-21 19:14:06 UTC
P.S.: Not sure if this is of any relevance, but this is a two-monitor setup where the main monitor has a fixed wallpaper from the KDE collection (which shows when the desktop finally shows up), and the second monitor has the slide show and stays blank at first.
Comment 3 Kai Uwe Broulik 2017-01-01 22:47:12 UTC
It doesn't noticeably slow down plasmashell startup here (didn't test actual login process). What does happen is that plasmashell keeps eating one core's power until it has finished indexing the folders. It can be used as normal during that, though.
Comment 4 Kai Uwe Broulik 2017-01-01 22:51:11 UTC
Ok, it might still do. I thought all of the slideshow processing was done in a separate thread, however, only finding the images is. After that the images are enqueued and further processed on the main thread which could cause massive blocking if done over the network.
Comment 5 Nate Graham 2019-11-14 00:47:59 UTC
Wallpaper processing was massively simplified for Plasma 5.17. Can anyone who was originally experiencing this issue still reproduce it in Plasma 5.17?
Comment 6 kde 2019-11-15 09:24:17 UTC
In fact, it has reappeared with 5.17, and the problem doesn't seem to be the slow NAS.

I meanwhile have a fast NAS and didn't see the problem for quite a while. It has reappeared now, though, slightly different, but still:

When I log in, I see the progress bar. It goes to 100% and the launch bar shows. It is frozen, however. I can move the mouse, but when I click on the launch bar or right-click on the desktop background, nothing happens. The time shown in the launch bar doesn't update.

After ~ 5 minutes, the background image is shown, and all mouse clicks I have done meanwhile are executed, the time in the launch bar updates, and I can use the system.

This problem has reappeared together with others that had been fixed before, and especially one of them (a very strange one) might have to do with this problem:

When I open an image on the NAS in Gwenview, it takes very long to load, some 30s or so. The spinner is frozen while it loads the image.

This does not happen when I open an image on the local disk with Gwenview (even the same one copied over). Also, the NAS itself is fast, I can copy files with > 100MB/s, and other (non-KDE) image viewers don't show the same problem.

This had been like that before, but was fixed. Now it reappeared, I think with 5.17.

In Gwenview, this has been fixed again with 5.17.3 now, it's quick again. But maybe whatever problem Gwenview had is still present in the code to show the wallpapers?

I can quickly go the next wallpaper image, though, no problem at that point.

One more thing I found looking at the logs:

Upon login, there are several thousand lines like the following:

Nov 15 09:46:34 zottel plasmashell[740]: kf5.kpackage: No metadata file in the package, expected it at: "/mnt/ds/photo/2011/110809 Besuch von Rettbergs/"

It seems that one of these lines is generated for every image file in the repository (i.e. as the directory mentioned in the log line above has around 50 files, there are ~ 50 identical lines like the one above, and then for all the other directories).

BTW, the NAS is a CIFS mount with read/write access.
Comment 7 kde 2019-11-15 09:44:05 UTC
Just looked, during my login today, there were 74,715 (!) log lines produced like the one mentioned in the comment above, between 09:46:02 and 09:47:49. It took until shortly before 09:51, however, before I was able to use the UI.
Comment 8 kde 2019-11-15 09:57:12 UTC
Just to add that (sorry, last comment for today): In the system journal, there are no log entries regarding KDE between 09:47:49 and 09:50:57, only a backup starting and triggering an automount:

[...]
Nov 15 09:50:57 zottel plasmashell[740]: qt.svg: <input>:663: Could not resolve property: #radialGradient3112
Nov 15 09:50:57 zottel plasmashell[740]: qt.svg: <input>:663: Could not resolve property: #radialGradient3118
Nov 15 09:50:02 zottel systemd[1]: Mounted /mnt/Backup.
Nov 15 09:50:02 zottel kernel: FS-Cache: Netfs 'nfs' registered for caching
Nov 15 09:50:02 zottel systemd[1]: Mounting /mnt/Backup...
Nov 15 09:50:02 zottel systemd[1]: mnt-Backup.automount: Got automount request for /mnt/Backup, triggered by 897 (borg)
Nov 15 09:50:01 zottel kernel: audit: type=1006 audit(1573807801.712:45): pid=895 uid=0 old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=4 res=1
Nov 15 09:50:01 zottel CROND[896]: (root) CMD (/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /root/borg)
Nov 15 09:50:01 zottel crond[895]: pam_unix(crond:session): session opened for user root by (uid=0)
Nov 15 09:47:49 zottel plasmashell[740]: kf5.kpackage: No metadata file in the package, expected it at: "/mnt/ds/photo/Nicole/Rosa Kamera/Kinderado/"
Nov 15 09:47:49 zottel plasmashell[740]: kf5.kpackage: No metadata file in the package, expected it at: "/mnt/ds/photo/Nicole/Rosa Kamera/Kinderado/"
[...]
Comment 9 Nate Graham 2019-11-15 13:11:24 UTC
Thanks for the info.
Comment 10 john.fano 2019-11-18 13:01:46 UTC
I don't believe this has anything to do with the NAS as I am also seeing this with wallpapers in my home folder.  I have about 13k wallpapers that I've collected over the years and they are all in my home folder on SSD's or NVMe drives in a dot folder named .wallpaper.  I have 4 machines and only 1 of them still works as expected.  I don't use a splash screen.  The login take about 20-30 seconds to load the desktop on 3 of my machines and the last one immediately goes to the desktop.  They are all using the same wallpapers synced with Seafile.  The lock screen takes the same.  The screen locks, but takes 20-30 seconds before it will display the first wallpaper.  Once it's going it's fine.  Except for the last machine where it locks and immediately shows an image.  On the 3 that exhibit this behavior, when it's trying to load an image you can't unlock the screen for that brief period.

I have the desktop set to change the wallpaper every 15 minutes and the lock screen changes every 15 seconds.

The three that are very slow to load the desktop or lock screen are on:

2 x Manjaro - Plasma 5.15.5, Frameworks 5.64.0, Qt 5.13.2
1 x Arch - Plasma 5.17.3, Frameworks 5.64.0, Qt 5.13.2

The one that still works as expected is running:

Manjaro - Plasma 5.15.5, Frameworks 5.61.0, Qt 5.13.0

The one that works has not been updated in a month or two, so something seems to have changes between those version differences.  I bet if I update this machine it will start doing the same thing.

It seems to be related to the number of wallpapers.  If I add the sub folders of images one by one it's good until I add more than around 1500 images, then it starts to show the delay.  The more you add the longer the delay.  If I remove the sub folders the delay shortens until I get below that 1500 mark and then it's immediate again.

I would be happy to test things with my machines, just let me know what you want me to do.

Thanks!
Comment 11 Nate Graham 2019-12-06 17:14:46 UTC
*** Bug 414897 has been marked as a duplicate of this bug. ***
Comment 12 Nate Graham 2019-12-06 17:14:56 UTC
*** Bug 413069 has been marked as a duplicate of this bug. ***
Comment 13 Yuking 2019-12-06 17:58:39 UTC
5.16.4 is OK, but 5.17.4 is very slow.
It seems that, in 5.17.4, the wallpaper plugin will check every image before desktop is usable, so, if there has many many images, this procedure will be very very slow.
Comment 14 Nate Graham 2019-12-13 11:22:06 UTC
*** Bug 415119 has been marked as a duplicate of this bug. ***
Comment 15 Little Jhonnes 2019-12-14 15:01:37 UTC
Hello! A few days ago I noticed a bug that made my kde lock screen crash and only come back a few minutes later, usually 10 to 15 minutes. This occurs when the lock screen is in "slideshow" mode and the folder (or folders) configured with the images has too many images. A similar bug occurs if the desktop is set to "slideshow" and the folder has too many wallpapers. In this case, what happens is that the system takes a long time to leave the presentation screen and go to the desktop. I do not know what the limit of wallpapers seems reasonable to the system, but the absurd amount I have (over 30 thousand) makes the system have this problem. When I used debian and kde was 5.12 I never noticed any of them, so it's probably something in kde 5.17, because even in 5.16, which I remember using in Manjaro, there weren't any of these problems
Comment 16 Little Jhonnes 2019-12-14 15:24:24 UTC
(In reply to Yuking from comment #13)
> 5.16.4 is OK, but 5.17.4 is very slow.
> It seems that, in 5.17.4, the wallpaper plugin will check every image before
> desktop is usable, so, if there has many many images, this procedure will be
> very very slow.

It was the best description. This occurs both for starting the system after the splash screen and for returning the lock screen login when slideshow with many wallpapers is set up.
Comment 17 Yuking 2019-12-26 12:07:05 UTC
Plasma works fine while just replacing plasma-workspace-5.17.4 with 5.16.4...
Comment 18 Nate Graham 2020-01-02 17:20:38 UTC
*** Bug 395972 has been marked as a duplicate of this bug. ***
Comment 19 Little Jhonnes 2020-01-02 17:56:17 UTC
Was it solved?
Comment 20 Nate Graham 2020-01-02 17:58:44 UTC
If it was, the bug would be marked as RESOLVED. :)
Comment 21 Sébastien P. 2020-01-04 19:40:33 UTC
*** Bug 413934 has been marked as a duplicate of this bug. ***
Comment 22 Sébastien P. 2020-01-04 19:41:37 UTC
(In reply to Nate Graham from comment #5)
> Wallpaper processing was massively simplified for Plasma 5.17. Can anyone
> who was originally experiencing this issue still reproduce it in Plasma 5.17?

Hi Nate!
This issue appears with 5.17 for me :/. No problem with 5.16.5.
I switched from frameworks 5.60 to 5.64 at the begging of December (no issue at that moment). I switched from 5.16.5 to 5.17.4 this week. It “created” the issue.
Comment 23 Sébastien P. 2020-01-04 19:43:27 UTC
As I said on the duplicate issue:
> plasmashell process with 100% CPU on one core during the switching of picture.
> 50Gio for 10929 files for me.
Comment 24 Christian 2020-01-09 10:59:11 UTC
Same here on Plasma 5.17.4 - this bug hit me when that version became stable on Gentoo amd64.

My large collection is on a local drive, i.e., the network is definitely not the problem.

Probably the same bug behaviour can be seen when opening the Background settings, choosing Slideshow, and then adding a folder with a large number of images (in subfolders). This causes the settings window to freeze for minutes.
Comment 25 Little Jhonnes 2020-01-13 05:49:07 UTC
Today there was one more update of kde and I still can not understand how a problem that a few weeks ago did not exist becomes part of the system in this way. After each update I test to see if it has been resolved and kde hangs for a few minutes. I'm even thinking of using variety again to have the same function on the system, at least in part. And thinking that was one of the things that made me true to kde so far. I wish the developers luck.I'm very sad about this.
Comment 26 Yuking 2020-01-17 15:07:56 UTC
Waiting for fixing this problem. Hope it is not a long time.
Comment 27 Christian 2020-01-20 05:40:20 UTC
I have no experience in debugging KDE but started comparing versions and files because this bug is "bugging me".

Could it be that this commit introduced the behaviour? It's the only change I could find that seems to be related to the background slideshow.
https://github.com/KDE/plasma-workspace/commit/ea32a7611227ca141bd60d983d1489d2be82d10f#diff-821d7994d425d401a2d150dca027d8dc

My guess is that replacing the old code:
m_timer.stop();
        m_slideshowBackgrounds.clear();
        m_unseenSlideshowBackgrounds.clear();
        BackgroundFinder *finder = new BackgroundFinder(this, m_dirs);
        m_findToken = finder->token();
        connect(finder, &BackgroundFinder::backgroundsFound, this, &Image::backgroundsFound);
        finder->start();

with the new code:
m_timer.stop();
    m_slideshowModel->reload(m_slidePaths);
    connect(m_slideshowModel, &SlideModel::done, this, &Image::backgroundsFound);

somehow causes the whole plasma background to wait until all the paths have been scanned. Maybe the purpose of starting the "finder" after connecting it was just this, to avoid the delay?

Just a guess.
Comment 28 Yuking 2020-01-22 16:08:28 UTC
Created attachment 125304 [details]
Desktop will not be frooze while a large amount of images presented when in slidemode
Comment 29 Yuking 2020-01-22 16:10:42 UTC
(In reply to Christian from comment #27)
> I have no experience in debugging KDE but started comparing versions and
> files because this bug is "bugging me".
> 
> Could it be that this commit introduced the behaviour? It's the only change
> I could find that seems to be related to the background slideshow.
> https://github.com/KDE/plasma-workspace/commit/
> ea32a7611227ca141bd60d983d1489d2be82d10f#diff-
> 821d7994d425d401a2d150dca027d8dc
> 
> My guess is that replacing the old code:
> m_timer.stop();
>         m_slideshowBackgrounds.clear();
>         m_unseenSlideshowBackgrounds.clear();
>         BackgroundFinder *finder = new BackgroundFinder(this, m_dirs);
>         m_findToken = finder->token();
>         connect(finder, &BackgroundFinder::backgroundsFound, this,
> &Image::backgroundsFound);
>         finder->start();
> 
> with the new code:
> m_timer.stop();
>     m_slideshowModel->reload(m_slidePaths);
>     connect(m_slideshowModel, &SlideModel::done, this,
> &Image::backgroundsFound);
> 
> somehow causes the whole plasma background to wait until all the paths have
> been scanned. Maybe the purpose of starting the "finder" after connecting it
> was just this, to avoid the delay?
> 
> Just a guess.

I committed a patch to fix this problem, please check it. It works well on my plasma git-pulling tonight.
Comment 30 Yuking 2020-01-22 16:35:11 UTC
(In reply to Christian from comment #27)
> I have no experience in debugging KDE but started comparing versions and
> files because this bug is "bugging me".
> 
> Could it be that this commit introduced the behaviour? It's the only change
> I could find that seems to be related to the background slideshow.
> https://github.com/KDE/plasma-workspace/commit/
> ea32a7611227ca141bd60d983d1489d2be82d10f#diff-
> 821d7994d425d401a2d150dca027d8dc
> 
> My guess is that replacing the old code:
> m_timer.stop();
>         m_slideshowBackgrounds.clear();
>         m_unseenSlideshowBackgrounds.clear();
>         BackgroundFinder *finder = new BackgroundFinder(this, m_dirs);
>         m_findToken = finder->token();
>         connect(finder, &BackgroundFinder::backgroundsFound, this,
> &Image::backgroundsFound);
>         finder->start();
> 
> with the new code:
> m_timer.stop();
>     m_slideshowModel->reload(m_slidePaths);
>     connect(m_slideshowModel, &SlideModel::done, this,
> &Image::backgroundsFound);
> 
> somehow causes the whole plasma background to wait until all the paths have
> been scanned. Maybe the purpose of starting the "finder" after connecting it
> was just this, to avoid the delay?
> 
> Just a guess.

Sorry, that patch has big prolem, please ignore it...
Comment 31 Yuking 2020-01-25 10:49:50 UTC
(In reply to Christian from comment #27)
> I have no experience in debugging KDE but started comparing versions and
> files because this bug is "bugging me".
> 
> Could it be that this commit introduced the behaviour? It's the only change
> I could find that seems to be related to the background slideshow.
> https://github.com/KDE/plasma-workspace/commit/
> ea32a7611227ca141bd60d983d1489d2be82d10f#diff-
> 821d7994d425d401a2d150dca027d8dc
> 
> My guess is that replacing the old code:
> m_timer.stop();
>         m_slideshowBackgrounds.clear();
>         m_unseenSlideshowBackgrounds.clear();
>         BackgroundFinder *finder = new BackgroundFinder(this, m_dirs);
>         m_findToken = finder->token();
>         connect(finder, &BackgroundFinder::backgroundsFound, this,
> &Image::backgroundsFound);
>         finder->start();
> 
> with the new code:
> m_timer.stop();
>     m_slideshowModel->reload(m_slidePaths);
>     connect(m_slideshowModel, &SlideModel::done, this,
> &Image::backgroundsFound);
> 
> somehow causes the whole plasma background to wait until all the paths have
> been scanned. Maybe the purpose of starting the "finder" after connecting it
> was just this, to avoid the delay?
> 
> Just a guess.

In 5.16, a QStringList stores all pictures' paths, but the information of each picture will not be checked before it is displayed. In 5.17, the QStringList is removed, and all pictures' information are checked while creating the background 's list. That is why it is so slow.
I tried to fixed it, but found the only way is rollbacking the codes to 5.16 ...
Comment 32 David Redondo 2020-01-26 14:53:16 UTC
Hi, does the following patch help? 
It shows the last image shown the last time on startup, which should signal ealier that wallpaper.loading = false;

diff --git a/wallpapers/image/image.cpp b/wallpapers/image/image.cpp
index b36d4f2d6..f9aff9ce8 100644
--- a/wallpapers/image/image.cpp
+++ b/wallpapers/image/image.cpp
@@ -107,6 +107,9 @@ void Image::componentComplete()
     if (m_mode == SingleImage) {
         setSingleImage();
     } else if (m_mode == SlideShow) {
+        // show the last image shown the last time
+        m_wallpaperPath = m_wallpaper;
+        emit wallpaperPathChanged();
         startSlideshow();
     }
 }
(END)
Comment 33 Christian 2020-01-26 20:15:36 UTC
(In reply to David Redondo from comment #32)
> Hi, does the following patch help? 
> It shows the last image shown the last time on startup, which should signal
> ealier that wallpaper.loading = false;

Thanks, David. The patch compiles and does show the last image shown the last time on startup. But it doesn't fix the problem:
* The plasmashell process still consumes huge amount of processing time immediately from the login
* During that time, many plasma things don't work, including the "Start menu" or whatever KDE calls it, the status bar with the notification icons, etc.

Maybe it helps to re-state what the problem is (the fact that the wallpaper doesn't show immediately, which you fixed in the patch, is only one problem). The main problem is that, now, Plasma appears to "scan and read" the whole image collection immediately after log-in (not sure what for), and this freezes the rest of plasma desktop for a considerable while. (More than 10 minutes on this machine... I.e., I don't log out any more, I just lock the screen instead, because logging in to a working system takes ages.)

In earlier versions, there was no problem like this. I don't know what changed internally, but the explanation in Comment #13 sounds correct to me.
Comment 34 Xwang 2020-01-26 20:21:53 UTC
Moreover as I've reported in this bug https://bugs.kde.org/show_bug.cgi?id=413934, the issue is that everytime the image is changed, you have a CPU high load spike.
Comment 35 Sébastien P. 2020-01-27 20:09:18 UTC
(In reply to Christian from comment #33)
> (In reply to David Redondo from comment #32)
> > Hi, does the following patch help? 
> > It shows the last image shown the last time on startup, which should signal
> > ealier that wallpaper.loading = false;
> 
> Thanks, David. The patch compiles and does show the last image shown the
> last time on startup. But it doesn't fix the problem:
> * The plasmashell process still consumes huge amount of processing time
> immediately from the login
> * During that time, many plasma things don't work, including the "Start
> menu" or whatever KDE calls it, the status bar with the notification icons,
> etc.

Same here. It does not solve the main issue.
Comment 36 Yuking 2020-02-11 12:27:18 UTC
The recent codes from git://anongit.kde.org changed, but now the desktop can only slideshow the images in the last path when plasmashell exit last time, the same bug as my patch in comment #28. 

So, was I right in my comment #31?
Comment 37 David Redondo 2020-02-13 20:48:10 UTC
Git commit a58bbc050723583d75a47a3f00d19f41d70d17a4 by David Redondo.
Committed on 13/02/2020 at 20:48.
Pushed by davidre into branch 'Plasma/5.18'.

Don't delay ksplash until the entire slideshow is loaded

Summary:
Instead of loading the model and then showing the last shown image, we can show
it early so that we signal "wallpaper.loading = false" earlier.

Test Plan: Have massive slideshow, login

Reviewers: davidedmundson, broulik, #plasma

Reviewed By: davidedmundson, #plasma

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D27084

M  +4    -1    wallpapers/image/image.cpp

https://commits.kde.org/plasma-workspace/a58bbc050723583d75a47a3f00d19f41d70d17a4
Comment 38 Sébastien P. 2020-02-15 10:17:57 UTC
(In reply to David Redondo from comment #37)
> Git commit a58bbc050723583d75a47a3f00d19f41d70d17a4 by David Redondo.
> Committed on 13/02/2020 at 20:48.
> Pushed by davidre into branch 'Plasma/5.18'.
> 
> Don't delay ksplash until the entire slideshow is loaded
> 
> Summary:
> Instead of loading the model and then showing the last shown image, we can
> show
> it early so that we signal "wallpaper.loading = false" earlier.
> 
> Test Plan: Have massive slideshow, login
> 
> Reviewers: davidedmundson, broulik, #plasma
> 
> Reviewed By: davidedmundson, #plasma
> 
> Subscribers: plasma-devel
> 
> Tags: #plasma
> 
> Differential Revision: https://phabricator.kde.org/D27084
> 
> M  +4    -1    wallpapers/image/image.cpp
> 
> https://commits.kde.org/plasma-workspace/
> a58bbc050723583d75a47a3f00d19f41d70d17a4

Hi,

Still the same issue on 5.17.5 with this patch:
* plasmashell 100%
* no slideshow during this time (it should?)
* system a bit slow
* after the loading, it shows the latest slideshow

I do not know if 5.18 instead of 5.17 will change that.
Comment 39 Nate Graham 2020-02-15 15:04:14 UTC
That commit landed for Plasma 5.18.x, not 5.17.x. Also it is not expected to fully fix the issue (or else the bug report would be closed) but is merely an improvement. We're still working on getting the whole thing fixed.
Comment 40 Brett Gardner 2020-04-09 23:34:54 UTC
I'm also seeing this under 5.17.5.

I tried to work around it by having a service which would randomly copy an image from my actual image directory into the directory I configured the slideshow wallpaper to source from, but ran into multiple other bugs.

1. If I purge the existing files from the directory, the slideshow plugin will go to a black screen with the error "file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/configuration/ConfigurationContainmentAppearance.qml:85:9: Unable to assign [undefined] to QQmlListProperty<QQuickItem>"

2. If I configure slideshow's order to "Date modified, newest first" I get strange behaviour, When I click "Apply", it correctly shows the newest image, but as soon as I close the config window, it reverts to the previous image, with no output in the journal
Comment 41 Sébastien P. 2020-05-24 20:35:30 UTC
It looks fine on 5.18.5. I switched yesterday and the login was quick, like before.
Comment 42 kde 2020-05-29 21:55:36 UTC
I'm on 5.18.5, too, and it's still as slow as before.
Comment 43 Sébastien P. 2020-05-29 22:43:09 UTC
Yeah. It is still slow (compare to 5.16) but better for me (looks quicker compare to 5.17).
Comment 44 Mihai Sorin Dobrescu 2020-06-30 08:40:20 UTC
Could it be the new ordering feature?
Might be needed to check if works better in the old way, where the sorting was done by the filesystem component. What do you think?
The filesystem way simply retrieves the files, but the custom ordering will retrieve the files, then sort them, in an additional step.
Comment 45 Nate Graham 2020-09-23 18:15:17 UTC
*** Bug 426879 has been marked as a duplicate of this bug. ***
Comment 46 Aaron Goldblatt 2020-09-26 05:53:35 UTC
This issue is still present in Ubuntu 20.10 (pre-release, I know):

Operating System: Kubuntu 20.10
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.14.2
Kernel Version: 5.8.0-19-generic
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-6600 CPU @ 3.30GHz
Memory: 31.2 GiB of RAM
Graphics Processor: GeForce GTX 1060 6GB/PCIe/SSE2
Comment 47 Nate Graham 2021-03-15 16:57:03 UTC
*** Bug 431256 has been marked as a duplicate of this bug. ***
Comment 48 Oded Arbel 2021-03-16 16:13:49 UTC
(In reply to Nate Graham from comment #47)
> *** Bug 431256 has been marked as a duplicate of this bug. ***

For me the problem isn't actually during login (the login may be slowed by the same issue, but its not very slow and it only happens once) - the problem I have, as documented in the above dup bug report, is that the extraneous directory scanning happens every time I open a plasma shell dialog - even not the wallpaper configuration.

This is a video showing the issue: http://test.geek.co.il/plasmashell-stuck-scanning-wallpapers.mp4 - in it you can me opening the system tray configuration dialog and waiting about 4 minutes until it is responsive, while plasma is scanning files and folders.

It does not look like a single scan - strace shows plasmashell iterating over the same folders and files multiple times where each file is scanned 8 times.

The weird thing is that this behavior seems to be centered around the path ~/.local/share/wallpapers - in my setup this contains a set of symbolic links to specific sub-folders in my wallpaper collection, or it could be a mount to NAS that contains the wallpaper collection, either way - in this setup I observed the behavior shown in the video. If I remove the symbolic links, or the mount, leaving ~/.local/share/wallpapers as an empty folder - then there is no problem: plasma dialogs are snappy and there is no freezing, regardless of how the wallpaper slideshow plugin is configured.
Comment 49 Aleix Pol 2022-03-23 12:39:49 UTC
Git commit 3bd7e1d087cbf760361e2d2f99541c6d9ef09210 by Aleix Pol.
Committed on 23/03/2022 at 01:08.
Pushed by apol into branch 'master'.

image: Lazy-load the slideshow model

So far we were loading the slideshow model right at startup which
iterates through all the backgrounds on the system.
This changes so that it's only created when it's needed, which helps to
remove some startup disk accesses.
It should also give us less background-related warnings at startup as
they won't be all checked immediately.

M  +22   -10   wallpapers/image/image.cpp
M  +3    -1    wallpapers/image/image.h
M  +3    -0    wallpapers/image/slidefiltermodel.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/3bd7e1d087cbf760361e2d2f99541c6d9ef09210
Comment 50 alex 2023-07-23 12:47:29 UTC
Still appears in 

Operating System: Kubuntu 20.04
KDE Plasma Version: 5.18.8
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
Kernel Version: 5.4.0-153-generic
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-10510U CPU @ 1.80GHz
Memory: 15.3 GiB of RAM

As soon as "wallpaper type" is switched to "Slideshow", two things happen:
1/ apparently, the dialog seems to search for ALL possible images (but WHY???????? who had the brilliant idea to automatically launch this process, rather than WAIT for at least one path to be added?????????)
2/ it is as good as impossible to add a wallpaper path
Comment 51 alex 2023-07-23 12:51:38 UTC
Also, Plasma seems to crash (hitting the "Windows" key no longer shows the system menu)
Comment 52 Nate Graham 2023-07-23 13:12:01 UTC
I'm afraid Plasma 5.18 is unfortunately no longer eligible for support or maintenance from KDE. It's over 3 years old! This bug was fixed after the release of 5.18. Please update to Plasma 5.27 as soon as your distro offers it to you; in your case, that would be by upgrading the distro to Kubuntu 34.04.

If you need support for Plasma 5.18, please contact your distro, who bears the responsibility of providing support for older releases. Thanks for understanding!
Comment 53 Oded Arbel 2023-07-23 23:03:17 UTC
Mi(In reply to Nate Graham from comment #52)
> in your case, that would be by upgrading the distro to Kubuntu
> 34.04.

You probably meant Kubuntu 24.04 - the next LTS release that will be made available 9 months from now. Updating from the (still supported, theoretically) 20.04 to the current supported LTS - 22.04, will still not solve this issue as it was apparently fixed for Plasma 5.25 and the fix was never backported to a 5.24 bug fix release - which is what Kubuntu 22.04 is carrying.

> If you need support for Plasma 5.18, please contact your distro, who bears
> the responsibility of providing support for older releases. Thanks for
> understanding!

Unfortunately it doesn't look like this issue will ever be addressed in an LTS update - it is likely considered too minor to warrant the backporting effort.

Alex, if updating to the non-LTS Kubuntu 23.04 is not an option for you (as I suspect it isn't), then other than backporting the fix yourself, or living with this issue for the next 9 months (plus how ever long it will take to certify your system for a new LTS), and assuming you need a base LTS but can update just Plasma to a more recent version - then I can recommend installing the Neon User Edition focal repository and updating Plasma from there - it features Plasma 5.26 that is compatible with Kubuntu 20.04, and though it is no longer  being updated, I expect it to continue to be available for a while (the 18.04 repo - bionic - is still there), and you'd still likely get better experience and support with that than using Plasma from the oldest sill supported Kubuntu LTS...
Comment 54 Nate Graham 2023-07-25 19:47:40 UTC
Oops, actually I meant to recommend Kubuntu 23.04. It's not an LTS release, but it has Plasma 5.27 in it.

Personally I don't recommend sticking with LTS releases. In my opinion they represent a false promise. You do get "stability", for certain definitions of stability; the definition that ends up actually being used tends to be "stability of bugginess": It simply has the bugs that it has. The bugs don't change. Sometimes, maybe, some of them might get fixed, but that's not guarantee of that. Mostly you're just stuck with a fixed, unchanging set of bugs. So if you're using an LTS version that has a major bug for you which has already been fixed in a newer version of the software, you're mostly out of luck.

I get that LTS distros feel like they fit into the conservative update scheduled of institutional users, but this has to be counterbalanced against the possibility of hitting a bad bug that's already fixed upstream that you don't have access to yet, which is exactly what's happening here.
Comment 55 Nate Graham 2023-07-25 19:49:34 UTC
Also JFYI, if you opt to overlay Neon repos on top of your Kubuntu LTS installation, you've already broken the distro's LTS promise by monkeying with it in a way that isn't covered by the LTS support contract. If you're willing to do that, you might as well just use the23.04 release of Kubuntu which is a cohesive product and not a franken-distro.
Comment 56 Oded Arbel 2023-07-25 22:16:27 UTC
While I agree with the sentiment, Nate, and as such I'm always running the current release - there are valid reasons to use an LTS release without restricting yourself to the version of Plasma that came with the LTS - you might want to make sure that the C compiler is the version from the LTS, with all of the LTS Caves, or the Python interpreter, because you user the system to support production services running on an LTS, but as the production service isn't using a desktop UI - maintaining that compatibility isn't important.

BTW - if keeping to a base LTS is just a false promise we can do without, then I would really love to see Neon target the current Ubuntu instead of the LTS - it would make my life a lot easier 😇.
Comment 57 Nate Graham 2023-07-26 17:55:20 UTC
I fully agree that Neon should drop the LTS distro base. Neon is itself a franken-distro, which is part of the reason why it unfortunately breaks so much. :(