I take many pictures, they fill a double digit number of TB, distributed on several disc partitions on several discs. Some of these discs are internal, some external. Not all of these are mounted all the time. Often the launch of Digikam takes very very long, because it wants to update the entire database. It would be very handy if one could set a default "ignore" command regarding database update, and then actively point toward the location of the directories where an update regarding new images or deleted images are wished by the user. That way digikam will in my case only need to handle a few thousand files at startup, instead of wasting time on controlling the status of an enormous number of image files, some of which are on storage devices not always mounted. Besides this - many thanks for a very nice image editing progamme! Reproducible: Always Expected Results: Much faster launch of digikam. No removal/adding of images in database just because some discs are not always mounted.
Where does it hang when scanning? When selecting an album or in the splashscreen? If in the splash, then imo it's also a bug not to be fixed with a separate option, but deferring the update after the launch.
Teemu, As Marcel explain somewhere in bugzilla (certainly another file), the scan process at startup is cu into part : 1 - scan for new album : while splash-screen 2 - scan for new items : after gui init, into progress manager. The step 1 can take a while due to SQlite problem. Probably due to DB interface design, this step cannot be moved after GUI init as step 2/ Here Marcel can certainly give better explanation than me. Gilles
Hi Teemu, I don't know what you call the splash-screen. What happens when I open digikam is that first the small opening windows is there for a short while, saying reading database etc. Then comes the main digikam window. In my setup with the list of databases on the left, the pictures in the current directory shown as thumbnails in the midle, and info about the selected picture on the right. It is as this stage that is that a percentage bar is showing, where normally it says "no actice process" at the bottom. This starts at a small percentage, and can take pretty long time to finish. It is clear that what happens is that it searches through the databases and updates its own database about changes regarding pictures in the databases. At this stage digikam will often semi chrash if I'm impatient, and try to enter into a new directory or do some other activity. By semi chrash I mean it freezes, when trying to kill it with mouse clicks it after a little while tells digikam it not running properly, and one get the option to terminate the process. To me that's not a real problem, one can just leave digikam to finish the database stuff. The real problem is that if one has a very large collection of pictures, it is very ineffective if digikam all the time tries to go through the whole lot when one opens digikam. It becomes an additional problem if some of the databases are on discs not always mounted. I don't know if it causes additional problems that the majority of my pictures are on VFAT formatted partitions. This because I use a mix of Linux and Windows software to manipulate pictures. To handle the database update problem effectively one option is obviously the possibility of forcing digikam to ignore updating its information about specific databases. Such that if a disc with a huge amount of pictures is not mounted, it doesn't fool digikam to believe information about those pictures and thumbnails should be removed from digikams own database. Next time it is mounted, it starts to include those pictures again and make thumbnails. I apologize if that is not what happens, but given the amount of time it takes, it is difficult to see what else could be happening. Kind regards and thanks for your work on digikam, Henrik Henrik Vedel Kastanie Alle 32, 3520 Farum, Denmark Phone: +45 44957528 Mobile: +45 20727064 Email: hamhenrik@gmail.com On 2015-04-05 09:33, Gilles Caulier wrote: > https://bugs.kde.org/show_bug.cgi?id=345643 > > Gilles Caulier <caulier.gilles@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |marcel.wiesweg@gmx.de > > --- Comment #2 from Gilles Caulier <caulier.gilles@gmail.com> --- > Teemu, > > As Marcel explain somewhere in bugzilla (certainly another file), the scan > process at startup is cu into part : > > 1 - scan for new album : while splash-screen > 2 - scan for new items : after gui init, into progress manager. > > The step 1 can take a while due to SQlite problem. Probably due to DB interface > design, this step cannot be moved after GUI init as step 2/ > > Here Marcel can certainly give better explanation than me. > > Gilles >
I can confirm that trying to use Digikam while it is scanning for new pictures can crash it and can only be closed by killing the process. At least in digikam 5.8.0 on Windows.