[digiKam-users] Problem with moving grouped images

[meku]

Filed bugs:
*Bug 402379* <https://bugs.kde.org/show_bug.cgi?id=402379> - Moving
location of RAW file causes loss of metadata
*Bug 402380* <https://bugs.kde.org/show_bug.cgi?id=402380> - Database
schema upgrade to V10 is incomplete

On Mon, 17 Dec 2018 at 00:23, meku <digikam at meku.org> 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 <metzpinguin at gmail.com> 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?
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20181221/a1b23118/attachment.html>