Bug 347348

Summary:	Moving a directory loses metadata in database associated with .cr2 raw files
Product:	[Applications] digikam	Reporter:	Kenneth Ingham <kdebugs>
Component:	Database-Files	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	RESOLVED FIXED
Severity:	critical	CC:	caulier.gilles, metzpinguin
Priority:	NOR
Version:	4.9.0
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed In:	4.13.0

Description Kenneth Ingham 2015-05-06 22:15:04 UTC

With two versions of digikam running, I move a directory(folder) from one location to another. The files, including the metadata sidecar files are properly moved. However, after the move, the .cr2 raw files no longer show any metadata. Looking in the sidecar file, I can see the tags, copyright, caption, etc. However, they do not show up with the thumbnails nor in the metadata side panel. Selecting read metadata from file to database does nothing (shouldn't it try reading the sidecar?).

JPEG, TIFF, and other files where the metadata is stored in the file itself seem to move OK; I am guessing that scanning a new directory picks it up. However, since digikam is doing the moving, shouldn't it know to update the database as it moves the files? And, it should be able to read metadata from the sidecar in any case.

Reproducible: Always

Steps to Reproduce:
1. Add metadata to a .cr2 file with sidecar storage.
2. Move the folder somewhere else.
3. Look at the new location.

Actual Results:
All raw files have lost metadata, but JPEG, TIFF, and other files where the metadata is stored in the file itself move OK.

Expected Results:
Metadata stored in the database moves with the files. Metadata in sidecar files should be able to be loaded into the database.

Possibly relevant packages:
digikam-4.9.0-1.1.x86_64
digikam-doc-4.9.0-1.1.noarch
digikam-debuginfo-4.9.0-1.1.x86_64
kipi-plugins-geolocation-4.9.0-1.1.x86_64
kipi-plugins-lang-4.9.0-1.1.noarch
kipi-plugins-acquireimage-debuginfo-4.9.0-1.1.x86_64
kipi-plugins-4.9.0-1.1.x86_64
libkipi-devel-14.12.3-16.1.x86_64
kipi-plugins-geolocation-debuginfo-4.9.0-1.1.x86_64
kipi-plugins-acquireimage-4.9.0-1.1.x86_64
kipi-plugins-debuginfo-4.9.0-1.1.x86_64
libkipi11-14.12.3-16.1.x86_64

Comment 1 Kenneth Ingham 2015-05-06 22:15:36 UTC

This is related to, but different from 326112.

Comment 2 Maik Qualmann 2015-05-07 06:10:47 UTC

The problem is not reproducible in a short test. All metadata from sidecar are displayed after moving the CR2 files. If the images are stored on a network or local drive?

Maik

Comment 3 caulier.gilles 2015-05-07 06:19:16 UTC

Same here : not reproducible with files in local collection.

Gilles Caulier

Comment 4 Kenneth Ingham 2015-05-07 16:01:14 UTC

This is bizarre.  It happened yesterday.  Today, I cannot reproduce it.  I will keep experimenting to figure out what the specific circumstances are.

Comment 5 Kenneth Ingham 2015-05-18 15:00:50 UTC

It just happened again. 

OK, this is weird.  The data was not showing up, and then when I went to gather additional data for this update, it was there.  Is there a noticeable delay (at least a couple of minutes) between moving and the data showing up in the database?

Comment 6 caulier.gilles 2015-05-18 15:09:27 UTC

It can be. This depend of many factor.

I think the most important is DB file fragmentation, especially if file size is big, refer to a huge collection of image, and is located to an hard drive.

Personalty, i use SSD to host BD (and also photo : 1Gb device). Time responsive is very very fast. I manage over 250Gb of photo.

Note : It miss a tool to check DB integrity in digiKam. There is a file in bugzilla about this topic.
Gilles

Comment 7 caulier.gilles 2015-05-18 15:10:43 UTC

It can be a good indicator to evaluate the CPU/Memory overload when it's happen. Perhaps something take a while and slow down DB on your system.

Gilles Caulier

Comment 8 caulier.gilles 2015-06-24 16:16:44 UTC

New digiKam 4.11.0 is available :

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?

Gilles Caulier

Comment 9 caulier.gilles 2015-08-17 11:26:20 UTC

digiKam 4.12.0 is out :

https://www.digikam.org/node/741

We need a fresh feedback using this release please...
Thanks in advance.

Gilles Caulier

Comment 10 Kenneth Ingham 2015-08-24 15:32:37 UTC

I do not see this problem with 4.11.

Thanks.