[digiKam-users] Odd problem with tags, a sort of 'ghost' tag

[meku]

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.

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:
https://github.com/mcdamo/digikam-scripts/blob/master/digikam-tags-check.sql


On Fri, 28 Sep 2018 at 02:16, Chris Green <cl at isbd.net> wrote:

> meku <digikam at meku.org> wrote:
> > [-- text/plain, encoding quoted-printable, charset: UTF-8, 42 lines --]
> >
> > That the image shows up when using the left sidebar but not the tags
> filter
> > suggests to me that your Tags tree is in an inconsistent state.
> >
> > Depending on your Digikam version and database backend this can happen
> when
> > creating or deleting Tags. I haven't confirmed if the Digikam maintenance
> > tool will correct this inconsistency, personally I use a script that will
> > rebuild the Tree when this happens.
> >
>
> Yes, I suspect that tag handling is not as robust as it might be.
> What does your "script that will rebuild the Tree" actually do?
>
> Going on from that can anyone tell me which Tag modification actions
> write to the database and which write to the image metadata?  ... and
> why doesn't Digikam always write to both?
>
> --
> Chris Green
> ·
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20180928/cdddbd22/attachment.html>