[digiKam-users] Duplicate images in database, but not in application. "hidden" dupe has right tags - how to restore?

Ty Mayn tyrus.mayn at gmail.com
Wed Apr 20 02:24:17 BST 2022


    Even for much smaller databases it is/would be inconvenient to have a
database doubled with duplicates especially if
the obsoleted  files carry the tags.       On one  occasion when I moved an
intact folder tree and its digikam4.db file
to a new UUID I manually edited the UUIDbefore continuing use .This was
dumb luck since i scarcely understood
 the nature and consequences of rescan at the time.
I can see how a rescan could occur not because the users back is turned but
because the user doesnt guess that it is happening.
if there is no forced warning with digikam asking permission to do so.
   So I ask:  Is there (or should there be) a configuration for rescan that
is verbose with  "what if"?
      By that I mean inform the user of the expected changes of the scan
perhaps by a sample.
Since I havent and dont rescan much with my small project I havent really
had the experience.
    Can digikam be configured to inform the user for  go ahead and should
some actions have a go back
that is not dependent on resorting to a backup?
e.g. "By sample it appears you have 100% new images by hash"
                 " It looks like this scan has a new folder that you have
not explicitly added"

I ask this on behalf of novice users like myself always in danger
Ty



On Sun, Apr 17, 2022 at 1:16 AM Maik Qualmann <metzpinguin at gmail.com> wrote:

> Status 4 means "Obsolete", ie a deleted image. Even if the file name is
> the
> same, it cannot be the same image, the file size and unique hash is
> different.
> There are a good 20,000 images between the deleted image with status 4 and
> the
> currently visible image with status 1, probably the edited image.
>
> I suspect your database was re-scanned after moving to the new machine.
> You
> probably haven't updated the collection path in the database. If the
> collection is local, the drive UUID must also be updated.
>
> If you still have a backup of the old database it would not be a problem
> to do
> this.
>
> Maik
>
> Am Sonntag, 17. April 2022, 01:05:39 CEST schrieb loup+digikamusers at lo-
> cal.org:
> > I was recently looking through my images and found a large number of
> > images missing tags that I KNOW I had assigned to them.
> >
> > I started investigating and noted that the image files in question had
> > multiple entries in the "digikam.db" database, as shown in the
> screenshot:
> >
> > Most of the entries had "4" in the status column, which I think means
> > "file missing" or something like that.  One of the entries is "1".
> >
> > I recently had re-built my computer with a new hard drive and moved
> > everything over to my new machine.  I thought I had kept everything
> > clean by just copying over the digikam database and pointing digikam to
> > it, but I guess something got messed up, because now the database has
> > multiple entries for the same file.
> >
> > How do I tell digikam that all of these entries are the same image, and
> > to use the tags from a particular one of those entries as the "correct"
> > tags?  For example, in the given screenshot, the image with id 245506
> > has the right tags, but its status is "4". When I select the image in
> > digikam, the tags shown are those that correspond with image id 457786.
> >
> > It would be quite a waste of time to re-tag all of these images. If I
> > have to do some SQL or python to fix the database, I can do that.  Yes,
> > I'll make a backup before I try anything weird.
> >
> > Thank you.
> >
> > -Ron
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20220419/b1c80726/attachment.htm>


More information about the Digikam-users mailing list