<div dir="ltr">Marc, <div>Now I see why you found the behave I said strange. <br></div><div>I just start to organize my tags in the tag manager.</div><div>I move a tag inside other, now where they affect ~800 pictures. <br></div><div>I created a tag called "0_object" and put a tag called "bicicleta" inside.</div><div>This time the DK ask about make the update of the pictures in front or background. </div><div>Before confirm I saved the metadata , apply the changes and get the metadata to compare. </div><div><br></div><div>Here is what they modify into my pictures : <a href="https://imgur.com/a/NORTy1T">https://imgur.com/a/NORTy1T</a> </div><div><br></div><div>This behave doesn't happen when I move the geotags, perhaps some bug (!?) .</div><div><br></div><div>Then I renamed the tag "0_object" to only "object" and they don't apply to the pictures , another bug!?</div><div><br></div><div>Well, I will avoid this organization of my tags now and wait for version 7 where I hope they solve these issues. </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter., 7 de jul. de 2020 às 17:35, Cesar Inacio Martins <<a href="mailto:cesar.inacio.martins@gmail.com">cesar.inacio.martins@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><p>> From 6.4 to 7.0 is mostly bugfixes (some related to writing to
the tag tree), so <br>> I don't think you'll ruin anything by trying a
beta version. In any case, I've heard <br>> (somewhere in this mailing
list) that the final 7.0 version will be released on the 10th of
July.</p>
<p></p><div>Nice! for sure I will install it as soon they be released. <br>( 18 July : <a href="http://digikam.1695700.n4.nabble.com/digiKam-users-7RC-Slide-Show-tp4713033p4713037.html" target="_blank">http://digikam.1695700.n4.nabble.com/digiKam-users-7RC-Slide-Show-tp4713033p4713037.html</a> )</div><div dir="ltr"><br></div><div dir="ltr"><p>> So, what you say is quite weird. Usually what takes more times is
writing to the files, <br>> but writing the changes to the database is
quite fast. How many pictures are we talking about?</p>
<p></p></div><div dir="ltr">Is 4143 pictures. <br>I understand the tag tree configuration isn't forward to the picture metadata. <br>If I configure the tree: geotagged/geo:lat=1234 and the picture don't have the tag "geotagged" they don't add it into the picture. </div><div>So, no changes in the picture file are made.<br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter., 7 de jul. de 2020 às 16:51, <<a href="mailto:marcpalaus@hotmail.com" target="_blank">marcpalaus@hotmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>From 6.4 to 7.0 is mostly bugfixes (some related to writing to
the tag tree), so I don't think you'll ruin anything by trying a
beta version. In any case, I've heard (somewhere in this mailing
list) that the final 7.0 version will be released on the 10th of
july.</p>
<p>So, what you say is quite weird. Usually what takes more times is
writing to the files, but writing the changes to the database is
quite fast. How many pictures are we talking about?</p>
<p>I also like to recreate my database from time to time. I just
delete digikam's database, and let it rebuild it from the metadata
in the pictures. It might take a few hours, but I do it every
several months and it's a way to be sure that your
database<->metadata changes are synchronized. So I am not
really worried about losing the database.<br>
</p>
<div>El 7/7/20 a les 21:43, Cesar Inacio
Martins ha escrit:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Marc,
<div>Thanks for your answers. </div>
<div><br>
</div>
<div>So, about version 6.4 , I choose it because is the last
official stable version. </div>
<div>I really don't like to put in risk my photos with a not
stable program.</div>
<div>(yes, I have backup and etc, but who want to recover from
backup.. very annoying right)</div>
<div><br>
</div>
<div>I hope the version 7 should be stable enough, then I
already will upgrade to it.</div>
<div><br>
</div>
<div>About the tag performance, what happened: </div>
<div>1) the moving of theses geotags took ~3 hours.</div>
<div> During this, the application don't consume more than 15%
of CPU and no disk write. </div>
<div> Apparently it worked only into the metadata database on
SQLite. </div>
<div> 2) Then I click on Album -> Write metadata to file </div>
<div> Remember that my configurations are set to lazy
synchronization.</div>
<div> Apparently they update few photos files, but I have no
sure what they did because there is no log in the application
to check.</div>
<div> They were very fast, took ~1 minute. </div>
<div> I believe they update other changes I was made before
and not that 8k tags.</div>
<div> Also because probably all photos with tag "geo:*"
already have the "geotagged" tag, so no changes need. </div>
<div> 3) now I also see the tree structure I did into the DK
don't go to the photo file, only the individual tags.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Em ter., 7 de jul. de 2020 às
16:25, <<a href="mailto:marcpalaus@hotmail.com" target="_blank">marcpalaus@hotmail.com</a>>
escreveu:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I
also migrated from Picasa to Digikam a while ago.<br>
<br>
<br>
Ok, so first of all, version 6.4 is a bit old now, and lots of
bugs have <br>
been fixed in the new 7.0 release (the final version will be
released in <br>
a few days, I think).<br>
<br>
The good thing with digikam, is that it respects the previous
metadata <br>
made by other software, but also saves the new metadata into
the file or <br>
sidecar so it's permanent. That means that, moving a tag
around a tree <br>
will trigger writing that change to all pictures that share
the tags <br>
that have been affected by the move/merge. Basically digikam
has to read <br>
and then write each one of the files. So for a large library,
it can <br>
take a while. But the idea is that you have a previous idea of
the <br>
hierarchy you want to implement, and minimize the number of
"moves" you <br>
want to make in the tree. (e.g. I have several "root" tags,
the main <br>
ones being People and Places, so moving a branch of places
outside of it <br>
can affect thousands of pictures).<br>
<br>
El 7/7/20 a les 15:52, Cesar Inacio Martins ha escrit:<br>
> Hi,<br>
><br>
> I'm new to Digikam , using version 6.4.<br>
> I imported my photo library which is ~70k photos.<br>
> I'm using SQLite over an SSD hard disk.<br>
><br>
> Before Digikam I use the Picasa Desktop to manage my
photos where I <br>
> always keep my organization and tags.<br>
> I also set geotag using a program called geosetter which
is very handy <br>
> to set all the geolocation of my photos (since my camera
is old and <br>
> don't have a GPS embedded into).<br>
> This program set for each photo the tags "geo:lat=#####"
and <br>
> "geo:lon=#####" .<br>
> I have this only in ~5% of my photos, which gives ~8k
tags (based into <br>
> this SQL: select count(*) from tags where name like
'geo:%'; ).<br>
><br>
> Now I'm trying to organize my tags inside of digicam.<br>
> I don't want to remove theses tags, I want to use the
tree set <br>
> resource for better organization.<br>
> However, at the "Tags Manager" moving theses tags inside
of a parent <br>
> tag (called geotagged) is very, very, very slow.<br>
> Tooks ~3 secs to move each tag inside them.<br>
> I check this monitoring the table TagsTree (with dbeaver
sqlclient : <br>
> select count(*) from TagsTree tt ;).<br>
> I already added an index over this table and Tags table
to see if <br>
> help, but appear to have no effect.<br>
> My guess is the slowness is into the client tree view
object where is <br>
> affecting the update process.<br>
><br>
> I don't know if affect this, but I have my metadata
configuration set <br>
> to "lazy sync"<br>
><br>
> Any tips?<br>
><br>
><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div></div>
</blockquote></div>