<div dir="ltr">Filed bugs:<div><a href="https://bugs.kde.org/show_bug.cgi?id=402379"><b>Bug 402379</b></a> <span id="gmail-summary_container">
      - <span id="gmail-short_desc_nonedit_display">Moving location of RAW file causes loss of metadata</span></span><br></div><div><a href="https://bugs.kde.org/show_bug.cgi?id=402380"><b>Bug 402380</b></a> <span id="gmail-summary_container">
      - <span id="gmail-short_desc_nonedit_display">Database schema upgrade to V10 is incomplete</span></span><span><span><br></span></span></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 17 Dec 2018 at 00:23, meku <<a href="mailto:digikam@meku.org">digikam@meku.org</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"><div dir="ltr">Thankyou Maik, I tested groups in a fresh database and there are no problems like you say.<div><br></div><div>So I dig deeper and discover that only RAW files are having this problem in my live database. Observing this further I uncover that when JPG files are moved to a new location they reuse their old ImageID in the database but strangely the RAW files are given new IDs every time they are moved.</div><div><br></div><div>Narrowing this down to the database, it appears that this was only because the Images.modificationDate field did not have millisecond accuracy in my live database, it was a DATETIME() field whereas in newly created databases this field is a DATETIME(3).</div><div><br></div><div>So I see two separate issues here:</div><div><br></div><div>Firstly at some time the Digikam database schema has changed the format of various fields (I noticed DATETIME => DATETIME(3) and INT(11) => BIGINT(20) throughout the database) but these changes have not been retroactively applied to existing databases.</div><div><br></div><div>And secondly, after the schema update the modificationDate fields will still not contain millisecond accuracy and doing a refresh does not appear to update this field. This means for users upgrading existing databases may continue to have issues with RAW files if they move their file/folder location. Issues may be losing groups (as in my experience) or losing other metadata (if not writing to sidecars or using lazy synchronisation).</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, 16 Dec 2018 at 03:03, Maik Qualmann <<a href="mailto:metzpinguin@gmail.com" target="_blank">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">Moving albums with grouped images works without problems, just tested again. <br>
Now comes the BUT: If a grouped image with the same hash is in the collection, <br>
it is identified as a copied image and removed from the group, it is the <br>
leader image, the entire group is dissolved. At the moment we can not keep the <br>
groups information in copied images or images recognized as identically.<br>
<br>
Maik<br>
<br>
Am Samstag, 15. Dezember 2018, 15:17:36 CET schrieb meku:<br>
> My recollection of DK5.9 and earlier was that moving a folder would destroy<br>
> any image groups that had been created. Now when I say moving a folder I<br>
> mean using Digikam interface to drag and drop the folder within the current<br>
> collection - so all file operations are handled by Digikam.<br>
> <br>
> In the latest DK6.0beta3 the situation is slightly different - moving a<br>
> folder still breaks the groups BUT now the group icons continue display on<br>
> the images even though showing/hiding grouped items has no effect.<br>
> <br>
> Ungroup command has no effect initially on these ghost groups, I suppose<br>
> because the groups are corrupt, and the only way to fix the display is<br>
> first to create new groups with these images - which show incorrect counts<br>
> for the number of items in the groups, apparently still counting the ghost<br>
> grouped items - and THEN ungrouping them to return to a clean slate.<br>
> <br>
> I experience this running latest Kubuntu with the appimage. Does this<br>
> happen to you to?<br>
<br>
<br>
<br>
<br>
</blockquote></div>
</blockquote></div>