Just to mention that: When I use a fixed wallpaper from the KDE collection, login is as quick as expected.

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.

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.

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.

Wallpaper processing was massively simplified for Plasma 5.17. Can anyone who was originally experiencing this issue still reproduce it in Plasma 5.17?

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.

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.

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/"
[...]

Thanks for the info.

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!

*** Bug 414897 has been marked as a duplicate of this bug. ***

*** Bug 413069 has been marked as a duplicate of this bug. ***

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.

*** Bug 415119 has been marked as a duplicate of this bug. ***

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

(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.

Plasma works fine while just replacing plasma-workspace-5.17.4 with 5.16.4...

*** Bug 395972 has been marked as a duplicate of this bug. ***

Was it solved?

If it was, the bug would be marked as RESOLVED. :)

*** Bug 413934 has been marked as a duplicate of this bug. ***

(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.

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.

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.

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.

Waiting for fixing this problem. Hope it is not a long time.

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.

Created attachment 125304 [details]
Desktop will not be frooze while a large amount of images presented when in slidemode

(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.

(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...

(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 ...

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)

(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.

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.

(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.

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?

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

(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.

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.

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

It looks fine on 5.18.5. I switched yesterday and the login was quick, like before.

I'm on 5.18.5, too, and it's still as slow as before.

Yeah. It is still slow (compare to 5.16) but better for me (looks quicker compare to 5.17).

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.

*** Bug 426879 has been marked as a duplicate of this bug. ***

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

*** Bug 431256 has been marked as a duplicate of this bug. ***

(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.

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

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

Also, Plasma seems to crash (hitting the "Windows" key no longer shows the system menu)

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!

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...

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.

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.

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 😇.

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. :(