<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">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">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>