*** Bug 336307 has been marked as a duplicate of this bug. ***

Do you use sqlite or mysql database ?

Gilles Caulier

Created attachment 88142 [details]
attachment-11208-0.html

I use sqlite.
--
Antonio Angelo


2014-08-07 9:05 GMT+02:00 Gilles Caulier <caulier.gilles@gmail.com>:

> https://bugs.kde.org/show_bug.cgi?id=324134
>
> --- Comment #2 from Gilles Caulier <caulier.gilles@gmail.com> ---
> Do you use sqlite or mysql database ?
>
> Gilles Caulier
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You voted for the bug.
>

I used mysql database when I have encoutered this issue.

Problem still reproducible using last digiKam 4.2.0 ?

Gilles Caulier

I just encountered the same problem using Digikam 4.5.0 with MySQL-backend.

More Info: 
Problem occured after batch renaming three pictures. 
After that, one pic remained, two have gone AWOL.
All Pictures are still visible in ordinary file browser, they are just missing in Digikam. 

Strange enough, when I use Digikam's filter mode and type in the file name of the missing pictures, Digikam finds (or thinks it finds) this picture. However, the displayed pic is the one which didn't get lost after the batch rename, not the missing one. I don't know why this picture should match the filter..

It's reproducable: Batch rename seems to kick out the first picture of the renamed batch :(.

No way to repair the database - I tried moving the affected folder out and in of Digikam's picture path, rescanning in between, and so on: The pictures are lost for Digikam.

I gues the database has to be scrapped completely. I don't know how many photos I "lost" this way before noticing the bug. Seems to my kind of critical... and judging from above comments, it does not only affect the experimental MySQL backend.

Maik,

I suspect a same dysfunction here in advance rename than BQM with ImageScanner...

Gilles

Gilles,

The malfunction of the description I can not reproduce. But it is possible with the renaming of one file, to remove the suffix. The file is then no longer visible in the album, and must be externally renamed again. That could be the problem.

Maik

The file extension is a very sensible feature used by digiKam to identify quickly type mime without to parse first byte of file which is time consuming.

I recommend to drop file extension renaming in AdvanceRename tool to prevent all dysfunction. Note that is always possible use file manager as Dolphin, but in this case users do it with know risk.

We can also put a small tips in GUI about this problem.

Gilles

New digiKam 4.11.0 is available with official PKG installer for OSX.

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

Can you reproduce the problem with this release ?

digiKam 4.12.0 is out.

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

Problem still reproducible ?

Gilles Caulier

Just hit this problem on 4.6.0, after renaming files in a folder (wanted the suffix to be lower case), only images left in the album are the ones that were lowercase to start with, from all other images in the folder (with uppercase suffix) have disappeared.  Entries are still in table 'Images', but no longer in 'Imageinformation'.  Reread metadata or rescan does not bring information back.  Please provide method for recovery from this bug.

Could this be a 'feature' of MYSQL trigger behaviour for trigger 'delete-image' ? This trigger removes information from various places, including 'Imageinformation', after a DELETE. on table 'Images';

Is the update of the image name implemented as a DELETE, then INSERT with same imageid ?, rather then an UPDATE SET....

I have been able to recover the data in following way against the digikam database:

CREATE TEMPORARY TABLE `orphans` SELECT DISTINCT `id` FROM `Images` WHERE `id` NOT IN (SELECT `imageid` FROM `ImageInformation`);
DELETE from `Images` WHERE `id` in (SELECT * FROM `orphans`);

Then when digikam gets started again, images are recovered, not sure if this process leaves rubbish or not, but it appears not.  Would be nice if a database tool could do this, recover information that has been somehow lost.

I have tried this several times and this issue is also reproducible in digiKam Version 5.0.0-beta6

I can confirm that the bug is still present in beta6 (MySQL). I had hoped that the MySQL rewrite would have fixed this bug.
Makes MySQL unusable if you want to avoid data loss...

Maybe this is related to bug #357617: During batch rename of video files, I encounter strange behaviour, e.g. Digikam tries to rename files it has already renamed and so on. Is there some basic flaw in the batch rename logic triggering errors under certain conditions?

Problem still present in 5.0b6: I simply cannot batch rename video files (not only MTS, but some times also MP4) reliably. Sometimes Digikam renames a bunch and then fails, often it tries to rename a file it has already renamed (and therefore claims - rightly - that the file is not present). Sometimes the error message stops the renaming process, sometimes the process goes on in the background?!?! I simply don't understand the behaviour, it's consistent only inasfar as that batch renaming video files fails.

Sorry, added the above comment to the wrong bug.

Additional observation which might be related:

Because of the missing pics after advanced rename, I DROPped the MySQL database and started from scratch. Digikam crashed twice after that, but then it scanned the collection anew. 

Everything seemed to be fine, but then I noticed that some pictures where missing. For my quite big collection I could  not look in every folder, but for the examples I found it seemed as if files with the same name, but the same extension in lower and upper case where missing (e.g. name.jpg and name.JPG). I renamed these pics and restarted Digikam, again two crashes (?!), but afterwards the missing pictures were there again. (As I said, only those missing files I noticed and which I renamed, might be that there are more missing...)

It might also be a problem with the MySQL database - in the beginning I had "Collation" as type, which I changed to some UTF8-type for the second attempt.

However, something seems to be wrong concerning the file name handling.

Larx,

To be sure that problem remain with Mysql DB interface only, can you check if problem exist with a Sqlite database. The schema are not the same and SQlite interface is more advanced than Mysql one...

Thanks in advance

Gilles Caulier

I filed the bug from comment 23 seperately, see #364131. 

I will try with SQLite when I find the time, however, SQLite is for my real life no option as it completely fails already for a familiy photo collection on a network drive to be handled from three different computers (digikam startup time especially on WLAN is to be measured in hours, a central MySQL server takes less than a minute...)

yes, but Sqlite is the complete DB backend currently. We want to be sure that it work as expected.

We have a student working this summer on Mysql backend. Comparing both, especially one as Sqlite give the expected results will help to finalize Mysql interface.

Gilles Caulier

Git commit d18903fa644affd5f2b3c275b2544a54a9d64782 by Maik Qualmann.
Committed on 02/07/2016 at 17:30.
Pushed by mqualmann into branch 'master'.

make MySQL text fields case-sensitive
FIXED-IN: 5.0.0

M  +1    -2    NEWS
M  +81   -37   data/database/dbconfig.xml.cmake.in
M  +4    -1    libs/database/coredb/coredbschemaupdater.cpp

http://commits.kde.org/digikam/d18903fa644affd5f2b3c275b2544a54a9d64782