<div dir="ltr"><div dir="ltr"><div dir="ltr">I have used a MySQL procedure to rebuild the entire tree in database so it is runs in seconds, whereas re-importing metadata from files takes several hours. The tags tree is a standard nested set model so there is much information on the internet about this type of tree structure.</div><div dir="ltr"><br></div><div>This solution is probably only applicable if you are using the external database option in Digikam, and always backup your database. The source is made available here: <a href="https://github.com/mcdamo/digikam-scripts/blob/master/digikam-tags-check.sql">https://github.com/mcdamo/digikam-scripts/blob/master/digikam-tags-check.sql</a></div><br class="gmail-Apple-interchange-newline"></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 28 Sep 2018 at 02:16, Chris Green <<a href="mailto:cl@isbd.net">cl@isbd.net</a>> wrote:<br></div><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" target="_blank">digikam@meku.org</a>> wrote:<br>
> [-- text/plain, encoding quoted-printable, charset: UTF-8, 42 lines --]<br>
> <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>
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>
<br>
-- <br>
Chris Green<br>
·<br>
<br>
</blockquote></div>