| 1 |
Wols Lists wrote: |
| 2 |
> On 24/12/19 18:35, Dale wrote: |
| 3 |
>> I'll try to see if I can get the actual error here in a bit, either a |
| 4 |
>> picture or the actual text. I only need one line because it is the same |
| 5 |
>> for them all except the name and path of the file. |
| 6 |
> I've just had an idea ... |
| 7 |
> |
| 8 |
> I think it was on LWN they were talking about how a directory scan on |
| 9 |
> linux can take absolutely ages, because as it goes through it pulls |
| 10 |
> everything into cache and knackers the system. (Which is why a lot of |
| 11 |
> programs go through the grief of using direct rather than buffered io.) |
| 12 |
> |
| 13 |
> Not sure which developer it was, but they've brought in a new mode which |
| 14 |
> leaves cache untouched (sort of). If it can retrieve the file from |
| 15 |
> cache, it does so. If it's not in cache, it pulls it in, processes it, |
| 16 |
> and drops it. That way the cache does not fill up with recently accessed |
| 17 |
> files that are never going to be touched again, and your system doesn't |
| 18 |
> start swapping like mad to save all this unwanted data. |
| 19 |
> |
| 20 |
> Maybe when that is enabled in plasmashell it'll fix the problem ... how |
| 21 |
> big is this directory that's being scanned? If it's similar or larger in |
| 22 |
> size to your ram that could be the problem. Even if it's rather less, if |
| 23 |
> other programs are using up your ram ... |
| 24 |
> |
| 25 |
> Cheers, |
| 26 |
> Wol |
| 27 |
> |
| 28 |
> |
| 29 |
|
| 30 |
|
| 31 |
I found out something else. In the old KDE3 days, it would start at |
| 32 |
login at the top directory and work its way down while remember the last |
| 33 |
image. If you logout and back in, it picks up where it left off at. |
| 34 |
KDE5 does something totally different. It scans every file and puts |
| 35 |
them in order by the name no matter what directory they are in. In |
| 36 |
other words, if I have 100 directories with a image named 0000.jpeg, |
| 37 |
then it will show the images named 0000.jpeg regardless of what |
| 38 |
directory they are in. When that is done, it then moves to say 0001.jpeg. |
| 39 |
|
| 40 |
How did I notice this you ask?? When I added a larger directory, I |
| 41 |
noticed it did a preview thing in another part of the dialog window. It |
| 42 |
also has a little checkbox to disable/enable that image. What I noticed |
| 43 |
was what I posted above, how it was putting the images in order. It |
| 44 |
just so happens that folder had some slideshow type images in it that |
| 45 |
are numbered in sequence. Thing is, in the preview they were all |
| 46 |
clumped together but were mixed up and not sorted by the directory they |
| 47 |
were in. I hate to say it but it is the same result as random done this |
| 48 |
way. |
| 49 |
|
| 50 |
So, it appears what several of you came up with is correct. It is |
| 51 |
building some sort of index/cache/whatever system to organize the |
| 52 |
images. That results in a lot of CPU time. The only question left, if |
| 53 |
I were to allow it to build that index/whatever, does it rebuild at each |
| 54 |
login or not?? |
| 55 |
|
| 56 |
I wonder, if I add each directory within wallpapers a few at a time if |
| 57 |
it would be workable. Would it build that index/whatever without |
| 58 |
locking up? Even if that works, would it then shows slideshow type |
| 59 |
directories in sequence or would it still jump to other directories? |
| 60 |
|
| 61 |
Find one possible answer and end up with more questions. ROFL |
| 62 |
|
| 63 |
Dale |
| 64 |
|
| 65 |
:-) :-) |
Archives