[Digikam-users] Some questions about digikam4.db
ignatius.reilly at free.fr
Wed Nov 9 18:57:10 GMT 2011
Strange - I recently migrated from 2.2.0 MySQL to 2.3.0 MySQL
The thumbnails are still in a separate DB.
Other puzzling thing:
upon deleting an image the entry remains in the main DB ("Images" table)
with status changed to "3" - it is not physically deleted, and the
delete is not cascaded to the thumbnails DB, hence the thumbnails table
is growing although I'm pruning my pictures...
I am not sure about the usefulness of this design...
Gilles Caulier thus spake on 09/11/11 09:26:
> Hi Anders,
> yes, thumbnails storing is probably a side effect of this huge size. I
> remember a thread where Francesco and Marcel speak about a problem with
> dedicated thumbs DB.
> To resume : something have be done between 2.1 and 2.3 to store thumb in
> main DB instead dedicated one.
> Try this : run digiKam in with a fresh account and look if thumb DB blow
> up size when you compute all thumbnails through dedicated batch tool
> (look into Tools menu). The goal is to look if this work around is
> always valid or if it have been fixed with 2.3.0
> Gilles Caulier
> 2011/11/9 Anders Stedtlund <falolaf at gmail.com <mailto:falolaf at gmail.com>>
> I currently use digiKam/kipi-plugins 2.2.0. (Building 2.3.0 at the
> I just recently looked at the digikam4.db and can see that the size of
> the has suddenly been ~4 times bigger. As I have a couple of backups
> around it seems that when I went from v.2.0.0 to 2.1.0 the db grew
> from ~24MB to ~100MB. I have a history of backups which dates back
> almost a year and the db size has been almost the same, ~24 all the
> time. I have not added that many new images that could explain the
> I have looked in the tables and I have found that the:
> Images table contains 962 images that doens't have any Album set.
> ImagesTags table have 1628 rows connected to images without an Album
> The oldest image is from 2010-07-25. At least some of the images have
> been moved from one album to another. Haven't checked them all. Could
> it be stray entries related to the move? Is there a routine "clean"
> the db from such entries?
> As suggested on the mailing list I have tried this:
> sqlite3 -line digikam4.db 'vacuum;'
> Sure the db size went down but only a MB or two.
> Another reflection:
> There seems to be a new table: Thumbnails. There are 4500 thumbnails
> in that, about 1/3 of my total no of images. I can see that none of
> the latest and none of the earliest images are in there. This table
> could explain most of the db size I think. But is it used and for
> I would be happy if someone could enlighten me.
> Digikam-users mailing list
> Digikam-users at kde.org <mailto:Digikam-users at kde.org>
More information about the Digikam-users