<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-09-27 18:10 GMT+02:00 Chris Green <span dir="ltr"><<a href="mailto:cl@isbd.net" target="_blank">cl@isbd.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">meku <<a href="mailto:digikam@meku.org">digikam@meku.org</a>> wrote:<br>
> [-- text/plain, encoding quoted-printable, charset: UTF-8, 42 lines --]<br>
<span class="">> <br>
> That the image shows up when using the left sidebar but not the tags filter<br>
> suggests to me that your Tags tree is in an inconsistent state.<br>
> <br>
> Depending on your Digikam version and database backend this can happen when<br>
> creating or deleting Tags. I haven't confirmed if the Digikam maintenance<br>
> tool will correct this inconsistency, personally I use a script that will<br>
> rebuild the Tree when this happens.<br>
> <br>
<br>
</span>Yes, I suspect that tag handling is not as robust as it might be. <br>
What does your "script that will rebuild the Tree" actually do?<br>
<br>
Going on from that can anyone tell me which Tag modification actions<br>
write to the database and which write to the image metadata?  ... and<br>
why doesn't Digikam always write to both?<br></blockquote><div><br></div><div>This is the legacy of the project (started in 2001, don't forget).</div><div><br></div><div>Some people want store in both, some other just in database (and never touch original image).</div><div><br></div><div>The last one is the default workflow.</div><div> </div><div>The complexity of the metadata hub (it's called like this in source code) is to be able to handle all case with tags, written from DK, outside, from another application (welcome interroperabilty), manage all kind of file formats, handle XMP side car, must support multi-threading.</div><div><br></div><div>All low level operations are delegate to Exiv2 library.</div><div><br></div><div>For tags, and multiple selection of items with different tags already assigned, we need to process a good merging, without lost anything, depending of tags list changes.</div><div><br></div><div>The maintenance is also tedious, especially to synchronize DB to image and vis-versa.</div><div><br></div><div>So, if you think that "<span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">tag handling is not as robust as it might be", well you welcome to take the train in source code and to improve it. The game is not so simple to manage, if you list all input conditions and all output states from the box.</span></div><div><br></div><div>Gilles Caulier</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-- <br>
Chris Green<br>
·<br>
<br>
</font></span></blockquote></div><br></div></div>