SUMMARY Since upgrading from Leap 15.4 -> Leap 15.5 the wallpaper-slideshow has a massive bug. After KDE started up, it shows one of the slides, but does not switch to next one. In this case, "Next Wallpaper" from right-click menu also does not work. Seems that the process for slideshow is not starting up properly. Sometimes it happens that this slideshow works for some time then stops silently. I display several user data this way on one of my screens. As this does not work any more,it is critical for me. STEPS TO REPRODUCE 1. Start up KDE 2. Watch behavior of desktop wallpaper 3. Temporary and very nasty workaround: As workaround, I can enter Desktop properties (right-click menu), select something different to "Slides", Click "Apply", select "Slides" again, Click "Apply" and "Ok". Then the slideshow usually works (again). OBSERVED RESULT Slideshow immediately (or after some hours) stops. EXPECTED RESULT Changing wallpapers SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: openSUSE Leap 15.5 (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
When you apply your workaround, does it stop working again after you restart the machine? Where are the images for the slideshow located? On a local disk or an external or remote disk? Are the image files all visible, or are any of them hidden (i.e. their filenames begin with a period)? What rexact Plasma version are you using?
Hello, Nate. There is a wide variety in this. In my office (dual screen, slideshow on secondary screen) it happens less often. In my weekend house (single screen) it happens on *every* KDE startup. Both computers have similar hardware setup (nVidia graphics card). My weekend PC has less RAM and a slightly weaker CPU, but that should not have any effect on this behavior sd all that perfectly worked with older version of openSUSE Leap. All system details (from Info Center): ---------------------------------------------------------- Operating System: openSUSE Leap 15.5 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 5.14.21-150500.55.12-default (64-bit) Graphics Platform: X11 Processors: 6 × AMD FX(tm)-6300 Six-Core Processor Memory: 23.4 GiB of RAM Graphics Processor: GeForce GT 710/PCIe/SSE2
You also asked for the location of files: ~/.kde4/share/wallpapers/slides/ This .kde4 path comes from older times (the system was upgraded many times). I also want to mention that my ~/.config/plasma-localerc is changed to: [Formats] LANG=de_DE@euro <---- THIS [Translations] LANGUAGE= This is required because the entire system is running on ISO-8859-15 and NOT using this damned UTF-8. This is necessary because of several good reasons and works on Leap 15.5 again, because patches (earlier needed) found into KDE back again (for correctly handling filenames with German Umlauts. --> But this also has no effect on the slideshow as this files are plain ASCII names (no special chars).
How strange. Leap 15.4 uses Plasma 5.26 and Leap 15.5 uses Plasma 5.27, so there shouldn't be many differences between the two slideshow plugins.
I am no developer of such things, so I do not know about details, but I am pretty sure that this can be caused by changed startup mechanism. Perhaps a race condition? See my other issue, where canonical scripts do not work any more because someone got the crazy idea to change that! Also the same minor change in version, that worked in previous version.
Hello, again. Meanwhile I can definitely confirm that this new KDE Slideshow plugin must have an internal problem. Yesterday I restarted the plugin by temporarily switching to a single wallpaper and then back to slideshow. Right now I noticed that within last 15 minutes it froze again. Neither "rightclick -> Next Wallpapaer" nor automatic wallpaper change happens now. So I have to repeat the double-change between single wallpaper and slideshow again. A possible trace... I use images that are replaced every 5 minutes by a separate process. This process retrieves pictures from my web cams and replaces previous ones. Is it possible that kde Slideshow in current version has a problem with that? I assume that KDE is not able to detect a stucking slideshow process and to restart it on demand. That would be too nice. But is there a way to either do that from a bash script in regular intervals, or to enforce a reload (= kill and new start) of KDE-Slideshow from commandline/bash ? This way I could do the sledgehammer method and restart the slideshow i.e. every hour.
> I use images that are replaced every 5 minutes by a separate process. This process retrieves pictures from my web cams and replaces previous ones. Is it possible that kde Slideshow in current version has a problem with that? That's an important clue. Will investigate later.
Yes, if you can have a look on that? It looks like this could be the reason when writing the new picture and switching to it overlap? As this freeze happens after a longer time again and again, and as this happens more often on shorter wallpaper change intervals, this is very likely the reason.
(In reply to Fushan Wen from comment #7) > > I use images that are replaced every 5 minutes by a separate process. This process retrieves pictures from my web cams and replaces previous ones. Is it possible that kde Slideshow in current version has a problem with that? > > That's an important clue. Will investigate later. Hello, Fushan Wen. Did you meanwhile find some time to have a look? I have the impression that this "wallpaper hangs" happen more frequently in my office than in my weekend house (from where the pictures are sent over Internet to my office PC. As the upstream is a bit slow, transmitting the new pictures needs some seconds. So it might also be the case that KDE slideshow tries to access the picture while it is currently re-written - and this causes the freeze? Following questions arise: 1. What method of replacing the pictures do you recommend? Actually I have a directory defined in slideshow, from where all pictures are displayed in alphabetical order. I use rsync to get all pictures updated in my office from remote storage. This rsync is initiated from remote through my VPN. This way the new file is written first under a different name and finally renamed. 2. Is there a way to restart the slideshow from a shell script? As workaround I could perhaps enforce a complete restart of wallpaper slideshow?
Can be caused by https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2840
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3183
> from where all pictures are displayed in alphabetical order. Then I am afraid I can't really help here. The fix is for random order.
Git commit e69e0a936c2a6ae6790e5ff8ddffdf7f0539a97b by Fushan Wen. Committed on 15/08/2023 at 16:11. Pushed by fusionfuture into branch 'master'. wallpapers/image: fix potential invalid slide index in `nextSlide` If the last wallpaper is deleted before `nextSlide` is called, the next time `nextSlide` is called, m_currentSlide is always increased by 1, which is an invalid index, causing the slideshow always stuck at the last wallpaper. M +1 -1 wallpapers/image/plugin/imagebackend.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/e69e0a936c2a6ae6790e5ff8ddffdf7f0539a97b
Git commit bb17444cbab7d76b18c9c4bf2294d3e87426fc6b by Fushan Wen. Committed on 15/08/2023 at 16:16. Pushed by fusionfuture into branch 'Plasma/5.27'. wallpapers/image: fix potential invalid slide index in `nextSlide` If the last wallpaper is deleted before `nextSlide` is called, the next time `nextSlide` is called, m_currentSlide is always increased by 1, which is an invalid index, causing the slideshow always stuck at the last wallpaper. (cherry picked from commit e69e0a936c2a6ae6790e5ff8ddffdf7f0539a97b) M +1 -1 wallpapers/image/plugin/imagebackend.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/bb17444cbab7d76b18c9c4bf2294d3e87426fc6b
Created attachment 160987 [details] attachment-1684382-0.html The absolutely bullet proof method would be to go to next element in Lizzy. of anything happens (locked, not found, whatever), reload the file list from scratch and proceed. Am 15. August 2023 16:16:50 MESZ schrieb Fushan Wen <bugzilla_noreply@kde.org>: >https://bugs.kde.org/show_bug.cgi?id=473088 > >--- Comment #14 from Fushan Wen <qydwhotmail@gmail.com> --- >Git commit bb17444cbab7d76b18c9c4bf2294d3e87426fc6b by Fushan Wen. >Committed on 15/08/2023 at 16:16. >Pushed by fusionfuture into branch 'Plasma/5.27'. > >wallpapers/image: fix potential invalid slide index in `nextSlide` > >If the last wallpaper is deleted before `nextSlide` is called, the next >time `nextSlide` is called, m_currentSlide is always increased by 1, >which is an invalid index, causing the slideshow always stuck at the >last wallpaper. > > >(cherry picked from commit e69e0a936c2a6ae6790e5ff8ddffdf7f0539a97b) > >M +1 -1 wallpapers/image/plugin/imagebackend.cpp > >https://invent.kde.org/plasma/plasma-workspace/-/commit/bb17444cbab7d76b18c9c4bf2294d3e87426fc6b > >-- >You are receiving this mail because: >You reported the bug. >
Created attachment 160988 [details] attachment-1685592-0.html The absolutely bullet proof method would be to go to next element in Lizzy. of anything happens (locked, not found, whatever), reload the file list from scratch and proceed. Even this can be enhenced. ALWAYS reload the file list before NextSlide. This way there exists always a valid list of files. Them increment the index. If it gets behind momentary list of files, set it back to first element. This method also allows increasing the list of pictures on the fly, because additional files may cause some confusion in one cycle (if new files get inserted before current index, but after reaching the end of list, it will work smoothly again. Am 15. August 2023 16:16:50 MESZ schrieb Fushan Wen <bugzilla_noreply@kde.org>: >https://bugs.kde.org/show_bug.cgi?id=473088 > >--- Comment #14 from Fushan Wen <qydwhotmail@gmail.com> --- >Git commit bb17444cbab7d76b18c9c4bf2294d3e87426fc6b by Fushan Wen. >Committed on 15/08/2023 at 16:16. >Pushed by fusionfuture into branch 'Plasma/5.27'. > >wallpapers/image: fix potential invalid slide index in `nextSlide` > >If the last wallpaper is deleted before `nextSlide` is called, the next >time `nextSlide` is called, m_currentSlide is always increased by 1, >which is an invalid index, causing the slideshow always stuck at the >last wallpaper. > > >(cherry picked from commit e69e0a936c2a6ae6790e5ff8ddffdf7f0539a97b) > >M +1 -1 wallpapers/image/plugin/imagebackend.cpp > >https://invent.kde.org/plasma/plasma-workspace/-/commit/bb17444cbab7d76b18c9c4bf2294d3e87426fc6b > >-- >You are receiving this mail because: >You reported the bug. >
> This method also allows increasing the list of pictures on the fly It already does so. > The absolutely bullet proof method would be to go to next element in Lizzy. of anything happens (locked, not found, whatever), reload the file list from scratch and proceed. That will hide the real problem, and the real problem will usually get more and more troublesome if not discovered.
Created attachment 160989 [details] attachment-1693695-0.html I hope it is no such stupid error I did in the past (programming in FreePascal). I did a "find first" and then "find next" every few minutes (scanning a directory) but forgot to release/free memory at the end. So it piled up dynamically allocated RAM until limits were exceeded. Am 15. August 2023 17:49:04 MESZ schrieb Fushan Wen <bugzilla_noreply@kde.org>: >https://bugs.kde.org/show_bug.cgi?id=473088 > >--- Comment #17 from Fushan Wen <qydwhotmail@gmail.com> --- >> This method also allows increasing the list of pictures on the fly > >It already does so. > >> The absolutely bullet proof method would be to go to next element in Lizzy. of anything happens (locked, not found, whatever), reload the file list from scratch and proceed. > >That will hide the real problem, and the real problem will usually get more and >more troublesome if not discovered. > >-- >You are receiving this mail because: >You reported the bug. >
The new files/deleted files are watched by KDirWatch, not manually done by the wallpaper plugin. There might be some problems for the random order but for the aplhabetical order I haven't found a clue.
Git commit de7c078bca04b786d4be585af6a5fec60f920323 by Fushan Wen. Committed on 16/08/2023 at 04:18. Pushed by fusionfuture into branch 'master'. wallpapers/image: add new wallpapers to list end if not in config dialog M +18 -1 wallpapers/image/plugin/autotests/test_imagelistmodel.cpp M +3 -2 wallpapers/image/plugin/autotests/test_imageproxymodel.cpp M +18 -1 wallpapers/image/plugin/autotests/test_packagelistmodel.cpp M +1 -1 wallpapers/image/plugin/autotests/test_slidefiltermodel.cpp M +2 -1 wallpapers/image/plugin/autotests/test_slidemodel.cpp M +2 -2 wallpapers/image/plugin/imagebackend.cpp M +2 -1 wallpapers/image/plugin/model/abstractimagelistmodel.cpp M +3 -1 wallpapers/image/plugin/model/abstractimagelistmodel.h M +17 -6 wallpapers/image/plugin/model/imagelistmodel.cpp M +1 -1 wallpapers/image/plugin/model/imagelistmodel.h M +6 -3 wallpapers/image/plugin/model/imageproxymodel.cpp M +4 -1 wallpapers/image/plugin/model/imageproxymodel.h M +17 -6 wallpapers/image/plugin/model/packagelistmodel.cpp M +1 -1 wallpapers/image/plugin/model/packagelistmodel.h M +3 -2 wallpapers/image/plugin/slidemodel.cpp M +2 -1 wallpapers/image/plugin/slidemodel.h https://invent.kde.org/plasma/plasma-workspace/-/commit/de7c078bca04b786d4be585af6a5fec60f920323
Created attachment 160998 [details] attachment-1766956-0.html Good morning. This might help finding the reason, too: My workstation is running 24/7. Yesterday morning I had to restart the slideshow in the morning. Today I get only two slides displayed alternating, when I click "Next wallpaper". All other slides are not displayed. I have absolutely no knowledge in programming for KDE or in c/c++. I can read and somehoe figure out what the program should do, but not more. So I can only help with describing effects, bit with checking code. Does Slideshow load/refresh/update the file list before every slide change? Or does KDirWatch work in the way inotifywait works, triggering on changes some other code section? I use rsync to get pictures replaced. Rsync creates a _temporary_ _hidden_ file inside the target dir, and moves/renames that file to the final name (hereby deleting the previous file) after completion. Is it possible that KDirWatch has a massive problem with that? (A file appearing = hidden during transmission, disappearing after very short tiime again = renaming it, a new file appearing = final name) If so, I could try a workaround by syncing the files to a dir out of KDirWatch's view and then locally copying them to the target dir. In case that inotifywait can ignore hidden files, this might work, but this is not the right way. Needing 3 different programs/scripts to replace 4 pictures without confusing Slideshow is a bit overkill. Am Mittwoch, 16. August 2023, 02:47:33 CEST schrieben Sie: > https://bugs.kde.org/show_bug.cgi?id=473088 > > --- Comment #19 from Fushan Wen <qydwhotmail@gmail.com> --- > The new files/deleted files are watched by KDirWatch, not manually done by > the wallpaper plugin. There might be some problems for the random order but > for the aplhabetical order I haven't found a clue.
Git commit be5496133f0692099dfce0d8726fc23ba0e59f37 by Fushan Wen. Committed on 16/08/2023 at 09:52. Pushed by fusionfuture into branch 'master'. wallpapers/image: fix slideshow not starting for few images or superfast computers If an ImageProxyModel loads the image list immediately before SlideModel::addDirs is completed, the file list in SlideModel will be incomplete, so also check the loading status when adding folders. M +1 -1 wallpapers/image/plugin/imagebackend.cpp M +2 -0 wallpapers/image/plugin/slidefiltermodel.cpp M +12 -4 wallpapers/image/plugin/slidemodel.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/be5496133f0692099dfce0d8726fc23ba0e59f37
Git commit 8eb5fbcc6263c6e761ccbcfa11919830be34a891 by Fushan Wen. Committed on 16/08/2023 at 10:13. Pushed by fusionfuture into branch 'Plasma/5.27'. wallpapers/image: fix slideshow not starting for few images or superfast computers If an ImageProxyModel loads the image list immediately before SlideModel::addDirs is completed, the file list in SlideModel will be incomplete, so also check the loading status when adding folders. (cherry picked from commit be5496133f0692099dfce0d8726fc23ba0e59f37) M +1 -1 wallpapers/image/plugin/imagebackend.cpp M +12 -4 wallpapers/image/plugin/slidemodel.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/8eb5fbcc6263c6e761ccbcfa11919830be34a891
Created attachment 161001 [details] attachment-1779372-0.html Hi, again. Am Mittwoch, 16. August 2023, 10:09:47 CEST schrieben Sie: > https://bugs.kde.org/show_bug.cgi?id=473088 > > --- Comment #22 from Fushan Wen <qydwhotmail@gmail.com> --- > Git commit be5496133f0692099dfce0d8726fc23ba0e59f37 by Fushan Wen. > Committed on 16/08/2023 at 09:52. > Pushed by fusionfuture into branch 'master'. > > wallpapers/image: fix slideshow not starting for few images or superfast > computers > > If an ImageProxyModel loads the image list immediately before > SlideModel::addDirs is completed, the file list in SlideModel > will be incomplete, so also check the loading status when > adding folders. Do I understand right, dat this can be caused by a simple race condition? If so, I was not so far away. I have absolutely no idea on how all this KDE software internally works, but can't a boolean be set before and cleared after "SlideModel::addDirs" to allow waiting before loading the image until that other process has finished? At least with Microcontrollers I do so. Don't know it this is also possible in KDE and cpp. Actually... Is it possible to replace the existing Slideshow by a testing version - in case that somebody wants me to test changes he applied? > M +1 -1 wallpapers/image/plugin/imagebackend.cpp > M +2 -0 wallpapers/image/plugin/slidefiltermodel.cpp > M +12 -4 wallpapers/image/plugin/slidemodel.cpp > > https://invent.kde.org/plasma/plasma-workspace/-/commit/be5496133f0692099dfc > e0d8726fc23ba0e59f37
> I have absolutely no idea on how all this KDE software internally works, but can't a boolean be set before and cleared after "SlideModel::addDirs" to allow waiting before loading the image until that other process has finished? This was just how it did before, but not very correctly.
Created attachment 161002 [details] attachment-1785086-0.html Am Mittwoch, 16. August 2023, 11:18:05 CEST schrieben Sie: > https://bugs.kde.org/show_bug.cgi?id=473088 > > --- Comment #25 from Fushan Wen <qydwhotmail@gmail.com> --- > > > I have absolutely no idea on how all this KDE software internally works, > > but can't a boolean > be set before and cleared after "SlideModel::addDirs" to allow waiting > before loading the > image until that other process has finished? > > This was just how it did before, but not very correctly. But it worked LOTS better than now. Do you see a short time possibility to fix this? From my side I don't have the skills to fix anything.
I am almost sure the bug is fixed now. Please give 5.27.8 a try when it is out.
Created attachment 161088 [details] attachment-2393517-0.html Hi, Fushan Wen. Is there a possibility to provide me a replacement file for my current version 5.27.4 (x64)? As I know SuSE, such changes will need long time. Am Mittwoch, 16. August 2023, 17:54:36 CEST schrieben Sie: > https://bugs.kde.org/show_bug.cgi?id=473088 > > Fushan Wen <qydwhotmail@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|--- |FIXED > Version Fixed In| |5.27.8 > Status|REPORTED |RESOLVED > Latest Commit| |https://invent.kde.org/plas > | |ma/plasma-workspace/-/commi > | |t/be5496133f0692099dfce0d87 > | |26fc23ba0e59f37 > > --- Comment #27 from Fushan Wen <qydwhotmail@gmail.com> --- > I am almost sure the bug is fixed now. Please give 5.27.8 a try when it is > out.
Can you report a bug on https://bugzilla.opensuse.org/ ? so I can submit a backport on OBS
Or you can download the latest plasma5-workspace on https://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_Leap_15.5/x86_64/ , and replace /usr/lib64/qt5/qml/org/kde/plasma/wallpapers/image/libplasma_wallpaper_imageplugin.so with the newest file, once 5.27.8 is out.
Created attachment 161089 [details] attachment-2394371-0.html You mean that I replace my 5.27.4 version of this particular file with version 5.27.8 ? Simply copy it? Am Montag, 21. August 2023, 15:00:37 CEST schrieben Sie: > https://bugs.kde.org/show_bug.cgi?id=473088 > > --- Comment #30 from Fushan Wen <qydwhotmail@gmail.com> --- > Or you can download the latest plasma5-workspace on > https://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_Leap_15 > .5/x86_64/ , and replace > /usr/lib64/qt5/qml/org/kde/plasma/wallpapers/image/libplasma_wallpaper_image > plugin.so with the newest file, once 5.27.8 is out.
In theory that should work, but I am not very sure.
Created attachment 161090 [details] attachment-2394936-0.html Doesn't sound very trustful, but it is a try. Isn't it easier when you send me this one file instead of downloading the entire bunch of Plasma only for it? I'd give it a try and in worst case I revert to previous (original) version. If you could email it to me? Please? Btw.: What was actually wrong in the code? Am Montag, 21. August 2023, 15:04:43 CEST schrieben Sie: > https://bugs.kde.org/show_bug.cgi?id=473088 > > --- Comment #32 from Fushan Wen <qydwhotmail@gmail.com> --- > In theory that should work, but I am not very sure.
https://download.opensuse.org/repositories/KDE:/Unstable:/Frameworks/openSUSE_Leap_15.5/x86_64/plasma5-workspace-5.27.7git.20230818T164654~88780c84-ku.164.4.x86_64.rpm The is the nightly build of Plasma/5.27 branch. Download and extract it, find the file, copy and replace
Git commit 79f494d6c61ff7e1e4f4e618447e322eda89ac84 by Fushan Wen. Committed on 21/08/2023 at 17:38. Pushed by fusionfuture into branch 'master'. wallpapers/image: fix random order update logic In SlideFilterModel, an added/deleted wallpaper is not always the last one, so `first` and `last` also needs to be taken into account. `m_randomOrder` stores the row numbers of the source model in a specific order. When a new wallpaper is added, the `first` argument is not always equal to `sourceModel->rowCount()`, and when the condition is not met, all the existing row numbers in `m_randomOrder` that >= `first` need to be increased by 1 (or the number of new wallpapers), to make space for new wallpapers. Vice versa when wallpapers are removed. M +75 -0 wallpapers/image/plugin/autotests/test_slidefiltermodel.cpp M +25 -6 wallpapers/image/plugin/slidefiltermodel.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/79f494d6c61ff7e1e4f4e618447e322eda89ac84
Created attachment 161092 [details] attachment-2413748-0.html OMG. I know why I do it "by hands" with findfirst/findnext. A little bit ancient, but it cannot fail. :) Thanks for explaining. Am Montag, 21. August 2023, 17:54:47 CEST schrieben Sie: > https://bugs.kde.org/show_bug.cgi?id=473088 > > --- Comment #35 from Fushan Wen <qydwhotmail@gmail.com> --- > Git commit 79f494d6c61ff7e1e4f4e618447e322eda89ac84 by Fushan Wen. > Committed on 21/08/2023 at 17:38. > Pushed by fusionfuture into branch 'master'. > > wallpapers/image: fix random order update logic > > In SlideFilterModel, an added/deleted wallpaper is not always the last > one, so `first` and `last` also needs to be taken into account. > > `m_randomOrder` stores the row numbers of the source model in a specific > order. When a new wallpaper is added, the `first` argument is not always > equal to `sourceModel->rowCount()`, and when the condition is not met, all > the existing row numbers in `m_randomOrder` that >= `first` need to be > increased by 1 (or the number of new wallpapers), to make space for new > wallpapers. Vice versa when wallpapers are removed. > > M +75 -0 wallpapers/image/plugin/autotests/test_slidefiltermodel.cpp > M +25 -6 wallpapers/image/plugin/slidefiltermodel.cpp > > https://invent.kde.org/plasma/plasma-workspace/-/commit/79f494d6c61ff7e1e4f4 > e618447e322eda89ac84
But the change is only for random order, other orders are not affected.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3207
Git commit f26f7b1ada1b6d8c8943d6f457ca68449951dd87 by Fushan Wen. Committed on 21/08/2023 at 20:47. Pushed by fusionfuture into branch 'Plasma/5.27'. wallpapers/image: fix random order update logic In SlideFilterModel, an added/deleted wallpaper is not always the last one, so `first` and `last` also needs to be taken into account. `m_randomOrder` stores the row numbers of the source model in a specific order. When a new wallpaper is added, the `first` argument is not always equal to `sourceModel->rowCount()`, and when the condition is not met, all the existing row numbers in `m_randomOrder` that >= `first` need to be increased by 1 (or the number of new wallpapers), to make space for new wallpapers. Vice versa when wallpapers are removed. (cherry picked from commit 79f494d6c61ff7e1e4f4e618447e322eda89ac84) M +62 -0 wallpapers/image/plugin/autotests/test_slidefiltermodel.cpp M +26 -6 wallpapers/image/plugin/slidefiltermodel.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/f26f7b1ada1b6d8c8943d6f457ca68449951dd87
Created attachment 161206 [details] attachment-3258900-0.html Hello, Fushan Wen. I have tested your modifications on two computers and I can confirm that they perfectly work. On one PC I used alphabetical order. That PC had also problems. Is there anything that can be done to get that also fixed? I think this happens when the file is updated in exactly that moment when it shall be displayed. So the file (partially) exists or is somehow locked because it is currently written. In case that an error occurs with one picture (I don't know if it is possible to detect a loading error), the slide show should wait some seconds and retry, and if there is still a failure, switch to the next picture. Am Montag, 21. August 2023, 20:57:32 CEST schrieben Sie: > https://bugs.kde.org/show_bug.cgi?id=473088 > > --- Comment #39 from Fushan Wen <qydwhotmail@gmail.com> --- > Git commit f26f7b1ada1b6d8c8943d6f457ca68449951dd87 by Fushan Wen. > Committed on 21/08/2023 at 20:47. > Pushed by fusionfuture into branch 'Plasma/5.27'. > > wallpapers/image: fix random order update logic > > In SlideFilterModel, an added/deleted wallpaper is not always the last > one, so `first` and `last` also needs to be taken into account. > > `m_randomOrder` stores the row numbers of the source model in a specific > order. When a new wallpaper is added, the `first` argument is not always > equal to `sourceModel->rowCount()`, and when the condition is not met, all > the existing row numbers in `m_randomOrder` that >= `first` need to be > increased by 1 (or the number of new wallpapers), to make space for new > wallpapers. Vice versa when wallpapers are removed. > (cherry picked from commit 79f494d6c61ff7e1e4f4e618447e322eda89ac84) > > M +62 -0 wallpapers/image/plugin/autotests/test_slidefiltermodel.cpp > M +26 -6 wallpapers/image/plugin/slidefiltermodel.cpp > > https://invent.kde.org/plasma/plasma-workspace/-/commit/f26f7b1ada1b6d8c8943 > d6f457ca68449951dd87