[digiKam-users] Problem with moving grouped images

[meku]

My recollection of DK5.9 and earlier was that moving a folder would destroy any image groups that had been created. Now when I say moving a folder I mean using Digikam interface to drag and drop the folder within the current collection - so all file operations are handled by Digikam.

In the latest DK6.0beta3 the situation is slightly different - moving a folder still breaks the groups BUT now the group icons continue display on the images even though showing/hiding grouped items has no effect.

Ungroup command has no effect initially on these ghost groups, I suppose because the groups are corrupt, and the only way to fix the display is first to create new groups with these images - which show incorrect counts for the number of items in the groups, apparently still counting the ghost grouped items - and THEN ungrouping them to return to a clean slate.

I experience this running latest Kubuntu with the appimage. Does this happen to you to?

[Maik Qualmann]

Moving albums with grouped images works without problems, just tested again.
Now comes the BUT: If a grouped image with the same hash is in the collection,
it is identified as a copied image and removed from the group, it is the
leader image, the entire group is dissolved. At the moment we can not keep the
groups information in copied images or images recognized as identically.

Maik

Am Samstag, 15. Dezember 2018, 15:17:36 CET schrieb meku:

> My recollection of DK5.9 and earlier was that moving a folder would destroy
> any image groups that had been created. Now when I say moving a folder I
> mean using Digikam interface to drag and drop the folder within the current
> collection - so all file operations are handled by Digikam.
>
> In the latest DK6.0beta3 the situation is slightly different - moving a
> folder still breaks the groups BUT now the group icons continue display on
> the images even though showing/hiding grouped items has no effect.
>
> Ungroup command has no effect initially on these ghost groups, I suppose
> because the groups are corrupt, and the only way to fix the display is
> first to create new groups with these images - which show incorrect counts
> for the number of items in the groups, apparently still counting the ghost
> grouped items - and THEN ungrouping them to return to a clean slate.
>
> I experience this running latest Kubuntu with the appimage. Does this
> happen to you to?

[meku]

Thankyou Maik, I tested groups in a fresh database and there are no problems like you say.

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.

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).

So I see two separate issues here:

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.

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).

On Sun, 16 Dec 2018 at 03:03, Maik Qualmann <[hidden email]> wrote:

Moving albums with grouped images works without problems, just tested again.
Now comes the BUT: If a grouped image with the same hash is in the collection,
it is identified as a copied image and removed from the group, it is the
leader image, the entire group is dissolved. At the moment we can not keep the
groups information in copied images or images recognized as identically.

Maik

Am Samstag, 15. Dezember 2018, 15:17:36 CET schrieb meku:
> My recollection of DK5.9 and earlier was that moving a folder would destroy
> any image groups that had been created. Now when I say moving a folder I
> mean using Digikam interface to drag and drop the folder within the current
> collection - so all file operations are handled by Digikam.
>
> In the latest DK6.0beta3 the situation is slightly different - moving a
> folder still breaks the groups BUT now the group icons continue display on
> the images even though showing/hiding grouped items has no effect.
>
> Ungroup command has no effect initially on these ghost groups, I suppose
> because the groups are corrupt, and the only way to fix the display is
> first to create new groups with these images - which show incorrect counts
> for the number of items in the groups, apparently still counting the ghost
> grouped items - and THEN ungrouping them to return to a clean slate.
>
> I experience this running latest Kubuntu with the appimage. Does this
> happen to you to?

[meku]

Filed bugs:

Bug 402379 - Moving location of RAW file causes loss of metadata

Bug 402380 - Database schema upgrade to V10 is incomplete

On Mon, 17 Dec 2018 at 00:23, meku <[hidden email]> wrote:

Thankyou Maik, I tested groups in a fresh database and there are no problems like you say.

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.

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).

So I see two separate issues here:

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.

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).

On Sun, 16 Dec 2018 at 03:03, Maik Qualmann <[hidden email]> wrote:

Moving albums with grouped images works without problems, just tested again.
Now comes the BUT: If a grouped image with the same hash is in the collection,
it is identified as a copied image and removed from the group, it is the
leader image, the entire group is dissolved. At the moment we can not keep the
groups information in copied images or images recognized as identically.

Maik

Am Samstag, 15. Dezember 2018, 15:17:36 CET schrieb meku:
> My recollection of DK5.9 and earlier was that moving a folder would destroy
> any image groups that had been created. Now when I say moving a folder I
> mean using Digikam interface to drag and drop the folder within the current
> collection - so all file operations are handled by Digikam.
>
> In the latest DK6.0beta3 the situation is slightly different - moving a
> folder still breaks the groups BUT now the group icons continue display on
> the images even though showing/hiding grouped items has no effect.
>
> Ungroup command has no effect initially on these ghost groups, I suppose
> because the groups are corrupt, and the only way to fix the display is
> first to create new groups with these images - which show incorrect counts
> for the number of items in the groups, apparently still counting the ghost
> grouped items - and THEN ungrouping them to return to a clean slate.
>
> I experience this running latest Kubuntu with the appimage. Does this
> happen to you to?