<div dir="ltr"><div><br></div><div>    Even for much smaller databases it is/would be inconvenient to have a database doubled with duplicates especially if <br></div><div>the obsoleted  files carry the tags.       On one  occasion when I moved an intact folder tree and its digikam4.db file <br></div><div>to a new UUID I manually edited the UUIDbefore continuing use .This was dumb luck since i scarcely understood</div><div> the nature and consequences of rescan at the time.<br></div><div><div> 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.</div><div>if there is no forced warning with digikam asking permission to do so.</div><div>   So I ask:  Is there (or should there be) a configuration for rescan that is verbose with  "what if"?</div><div>      By that I mean inform the user of the expected changes of the scan  perhaps by a sample.</div><div>Since I havent and dont rescan much with my small project I havent really had the experience.</div><div>    Can digikam be configured to inform the user for  go ahead and should some actions have a go back</div><div>that is not dependent on resorting to a backup?<br></div><div>e.g. "By sample it appears you have 100% new images by hash"</div><div>                 " It looks like this scan has a new folder that you have not explicitly added"</div><div><br></div><div>I ask this on behalf of novice users like myself always in danger</div><div>Ty<br></div> <br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 17, 2022 at 1:16 AM Maik Qualmann <<a href="mailto:metzpinguin@gmail.com">metzpinguin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Status 4 means "Obsolete", ie a deleted image. Even if the file name is the <br>
same, it cannot be the same image, the file size and unique hash is different. <br>
There are a good 20,000 images between the deleted image with status 4 and the <br>
currently visible image with status 1, probably the edited image.<br>
<br>
I suspect your database was re-scanned after moving to the new machine. You <br>
probably haven't updated the collection path in the database. If the <br>
collection is local, the drive UUID must also be updated.<br>
<br>
If you still have a backup of the old database it would not be a problem to do <br>
this.<br>
<br>
Maik<br>
<br>
Am Sonntag, 17. April 2022, 01:05:39 CEST schrieb loup+digikamusers@lo-<br>
<a href="http://cal.org" rel="noreferrer" target="_blank">cal.org</a>:<br>
> I was recently looking through my images and found a large number of<br>
> images missing tags that I KNOW I had assigned to them.<br>
> <br>
> I started investigating and noted that the image files in question had<br>
> multiple entries in the "digikam.db" database, as shown in the screenshot:<br>
> <br>
> Most of the entries had "4" in the status column, which I think means<br>
> "file missing" or something like that.  One of the entries is "1".<br>
> <br>
> I recently had re-built my computer with a new hard drive and moved<br>
> everything over to my new machine.  I thought I had kept everything<br>
> clean by just copying over the digikam database and pointing digikam to<br>
> it, but I guess something got messed up, because now the database has<br>
> multiple entries for the same file.<br>
> <br>
> How do I tell digikam that all of these entries are the same image, and<br>
> to use the tags from a particular one of those entries as the "correct"<br>
> tags?  For example, in the given screenshot, the image with id 245506<br>
> has the right tags, but its status is "4". When I select the image in<br>
> digikam, the tags shown are those that correspond with image id 457786.<br>
> <br>
> It would be quite a waste of time to re-tag all of these images. If I<br>
> have to do some SQL or python to fix the database, I can do that.  Yes,<br>
> I'll make a backup before I try anything weird.<br>
> <br>
> Thank you.<br>
> <br>
> -Ron<br>
<br>
<br>
<br>
<br>
</blockquote></div>