Can I make re-read of albums a bit faster?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Can I make re-read of albums a bit faster?

Daniel Bauer-2
Hello,

I had to reorganize some albums. Because of digikams - pardon! -
disastrous folder-tree gui *2) I had to do that that outside of digikam
while digikam was closed.

When I reopened digikam, of course the new tree-organisation was not
represented. So I selected the sub-folder that now contains the recently
moved sub-sub-folders *1) and pressed F5 to rebuild the tree.

Now it shows me 80% in the progress bar, it took alt least half an hour
from 79%.... I guess in 2017 or 2018 it will be finished but I cannot
wait that long ;-) , so I ask:

Is there's a possibility or a tool that can do this thread a bit faster?

Thanks for hints!

Daniel


*1) It's a lot of albums and data that I moved (299 Folders with 8231
files, 125.1 GB), but that amount shouldn't make a problem for a
database system, doesn't it? I use no tags, nothing alike. Just albums
with files in them...

*2) when ever I move an sub-album by drag and drop, it closes the
containing sub-album tree and the remaining tree moves to another
position leaving me searching the position of the desired album with a
nervous opening/closing of sub-albums, making it impossible to drop the
album at the right place...
--
Daniel Bauer photographer Basel Barcelona
professional photography: http://www.daniel-bauer.com
google+: https://plus.google.com/109534388657020287386
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: Can I make re-read of albums a bit faster?

Peter Mc Donough
Am 27.12.2013 19:44, schrieb Daniel Bauer:

> Hello,
>
> I had to reorganize some albums. Because of digikams - pardon! -
> disastrous folder-tree gui *2) I had to do that that outside of digikam
> while digikam was closed.
>
> When I reopened digikam, of course the new tree-organisation was not
> represented. So I selected the sub-folder that now contains the recently
> moved sub-sub-folders *1) and pressed F5 to rebuild the tree.
>
> Now it shows me 80% in the progress bar, it took alt least half an hour
> from 79%.... I guess in 2017 or 2018 it will be finished but I cannot
> wait that long ;-) , so I ask:

This is Murphy's Law of Computing.

If you do something for the first time on your computer, it is very
likely that:

a) it may not work as expected, if it works at all,
b) if it works, it will take much longer than expected,
c) more urgent work will become impossible while your new work is
running for the first time on your computer.

There are some settings in Digikam 3.5/Linux (German version -
Extras/Wartung, which should be extras/maintenance in English) which
influence the processing speed of database operations.
My experience: pick only the setting which are really relevant at that time.

cu
Peter

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: Can I make re-read of albums a bit faster?

Peter Mc Donough
Am 27.12.2013 20:56, schrieb Peter Mc Donough:
> Am 27.12.2013 19:44, schrieb Daniel Bauer:
>> I had to reorganize some albums. ...
>
> There are some settings in Digikam 3.5/Linux ...

I also remember that very much swap-space was necessary for digikam.
Additionally to my 4GB of main memory, is have 8GB swap-space on my HD.

If you run Windows it might be a good idea to let your system set
maximum swap-space.

cu
Peter



_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users
Reply | Threaded
Open this post in threaded view
|

Re: Can I make re-read of albums a bit faster? (solved, more or less...)

Daniel Bauer-2
So, I closed all other tasks, re-niced the digikam process and gave it
maximum priority in cpu and disk. This made it much, but MUCH!, faster.
It finished within few Minutes. I didn't have to wait for the next
century, hurray :-)

I have 16GB mem and a quite fast processor. It did not use swap. I have
the feeling that it was the disk access that made it so extremely slow.
Don't know, but after giving digikam maximum disk access, I heard the
disk working hard, while usually I don't hear it.

Well, for me the problem is solved for the moment, but maybe it would be
a good idea to check if this part of the program could be optimized
somehow....

With thanks for a great tool to the developers and the best wishes for a
great new year to all of you,

Daniel

Am 27.12.2013 21:40, schrieb Peter Mc Donough:

> Am 27.12.2013 20:56, schrieb Peter Mc Donough:
>> Am 27.12.2013 19:44, schrieb Daniel Bauer:
>>> I had to reorganize some albums. ...
>>
>> There are some settings in Digikam 3.5/Linux ...
>
> I also remember that very much swap-space was necessary for digikam.
> Additionally to my 4GB of main memory, is have 8GB swap-space on my HD.
>
> If you run Windows it might be a good idea to let your system set
> maximum swap-space.
>
> cu
> Peter
>
>
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

--
Daniel Bauer photographer Basel Barcelona
professional photography: http://www.daniel-bauer.com
google+: https://plus.google.com/109534388657020287386
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users