[digiKam-users] Tags manage - performance

[Cesar Inacio Martins]

Hi Marc,
Thanks for your answers.

So, about version 6.4 , I choose it because is the last official stable
version.
I really don't like to put in risk my photos with a not stable program.
(yes, I have backup and etc, but who want to recover from backup.. very
annoying right)

I hope the version 7 should be stable enough, then I already will upgrade
to it.

About the tag performance, what happened:
1) the moving of theses geotags took ~3 hours.
  During this, the application don't consume more than 15% of CPU and no
disk write.
  Apparently it worked only into the metadata database on SQLite.
 2) Then I click on Album -> Write metadata to file
  Remember that my configurations are set to lazy synchronization.
  Apparently they update few photos files, but I have no sure what they did
because there is no log in the application to check.
  They were very fast, took ~1 minute.
   I believe they update other changes I was made before and not that 8k
tags.
   Also because probably all photos with tag "geo:*" already have the
"geotagged" tag, so no changes need.
 3) now I also see the tree structure I did into the DK don't go to the
photo file, only the individual tags.

That said, for me, the application still have a logic to do this movement
of tags where don't get into consideration a high volume of tags or was
never tested with this objective.



Em ter., 7 de jul. de 2020 às 16:25, <marcpalaus at hotmail.com> escreveu:

> I also migrated from Picasa to Digikam a while ago.
>
>
> Ok, so first of all, version 6.4 is a bit old now, and lots of bugs have
> been fixed in the new 7.0 release (the final version will be released in
> a few days, I think).
>
> The good thing with digikam, is that it respects the previous metadata
> made by other software, but also saves the new metadata into the file or
> sidecar so it's permanent. That means that, moving a tag around a tree
> will trigger writing that change to all pictures that share the tags
> that have been affected by the move/merge. Basically digikam has to read
> and then write each one of the files. So for a large library, it can
> take a while. But the idea is that you have a previous idea of the
> hierarchy you want to implement, and minimize the number of "moves" you
> want to make in the tree. (e.g. I have several "root" tags, the main
> ones being People and Places, so moving a branch of places outside of it
> can affect thousands of pictures).
>
> El 7/7/20 a les 15:52, Cesar Inacio Martins ha escrit:
> > Hi,
> >
> > I'm new to Digikam , using version 6.4.
> > I imported my photo library which is ~70k photos.
> > I'm using SQLite over an SSD hard disk.
> >
> > Before Digikam I use the Picasa Desktop to manage my photos where I
> > always keep my organization and tags.
> > I also set geotag using a program called geosetter which is very handy
> > to set all the geolocation of my photos (since my camera is old and
> > don't have a GPS embedded into).
> > This program set for each photo the tags "geo:lat=#####" and
> > "geo:lon=#####" .
> > I have this only in ~5% of my photos, which gives ~8k tags (based into
> > this SQL: select count(*) from tags where name like 'geo:%'; ).
> >
> > Now I'm trying to organize my tags inside of digicam.
> > I don't want to remove theses tags, I want to use the tree set
> > resource for better organization.
> > However, at the "Tags Manager" moving theses tags inside of a parent
> > tag (called geotagged) is very, very, very slow.
> > Tooks ~3 secs to move each tag inside them.
> > I check this monitoring the table TagsTree (with dbeaver sqlclient :
> > select count(*) from TagsTree tt ;).
> > I already added an index over this table and Tags table to see if
> > help, but appear to have no effect.
> > My guess is the slowness is into the client tree view object where is
> > affecting the update process.
> >
> > I don't know if affect this, but I have my metadata configuration set
> > to "lazy sync"
> >
> > Any tips?
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20200707/3f9c1a50/attachment.htm>