[digiKam-users] album changes removal without reduction in thumbnail.db or digikam4.eb

Maik Qualmann metzpinguin at gmail.com
Sat Jan 22 07:16:16 GMT 2022


When items are deleted from databases, the database does not shrink. The 
entries are only marked as deleted and later overwritten by new items. If a 
database is to become smaller again, a vacuum process must be carried out. 
This is possible in digiKam's maintenance tool. However, the vacuum function 
was first revised again in digiKam-7.5.0 and may not always work in smaller 
digiKam versions. However, one should not overdo it with the vacuum of 
databases. 

Maik

Am Samstag, 22. Januar 2022, 02:41:46 CET schrieb Ty Mayn:
> In my narrative of this behavior I cant be sure how my backup image
> collection became duplicated into the digi databases
> It could easily have been confused experimenting on my part.  But i have
> carefully witnessed an album removal without a concurrent shrinking of any
> digikam database (thumbnail file especially observed)
>     The point of this post is that I carefully watched the outcome of using
> the trash can choice to remove the unwanted collection and carefully the
> databases did not change byte size.    The removed listing was in the
> category " collections of portable media"   The listing surely did
> disappear and the entire Tree for that collections of duplicates also
> disappeared from the Browser pane. I did that removal while having the
> actual collection out of reach (thumbnail not plugged in)
> In later iterations of digikam if I plug that thumbnail back in there is
> certainly no "revival" the deleted collection
>     But the 4 digikam files remain the same size as before removal and
> during multliple startups
> The only change in each of these files in a new startup is the date of
> access and modify attribute. EAch file content remains identical byte size.
> How do you instruct Digikam to actually downsize the thumbnails (should
> reduce roughly by half) or any other file during a removal?
> Ty
> 
> On Thu, Jan 20, 2022 at 8:17 PM Ty Mayn <tyrus.mayn at gmail.com> wrote:
> >  Forgive this newbie for using Digikam6  in this testing, I will upgrade
> > 
> > soon
> > During a variety of testing where I was using a thumbdrive for backups of
> > key digikam files, I acquired a complete duplicate album. I discovered my
> > new double vision (ha ha) in Dates view when I clicked on a date cluster.
> > 
> >      My testing had been in the Tags arena where the incoming duplicates
> > 
> > went unnoticed. So I am fairly sure that digikam rendered this service
> > automatically and my next "experiment" has been to remove that unwanted
> > duplicate collection which has identical recursive collection of image
> > folders as my testing collection
> > 
> >    I go to Settings>Configure>Collections to find the removable media
> > 
> > "root album"
> > 
> >      I used the trash icon which promptly removed the unwanted removable
> > 
> > media collection and offered me the opportunity to "Add"
> > 
> >      But I noticed no disk activity, the digikam4 .db remained the same
> > 
> > and the double sized thumbnail db went unchanged with no removal of
> > uneeded
> > thumbnails.  This remained true on shutdown and restart of digikam.
> > 
> >      I think I have accurate recall that digikam acquired that removable
> > 
> > collection without my request  yet it doesnt remove it on explicit
> > request.
> > 
> >  I am seeking some understanding this as a fundamental maintenance step
> > 
> > that I could encounter anytime in my future use of digikam
> > 
> >      Thanks for leading another novice
> > 
> > Ty






More information about the Digikam-users mailing list