344800 2015-03-03 20:44:18 +0000 SQLITE : when moving an album to another location tags are lost (NFS storage) 2020-09-05 20:08:37 +0000 1 1 2 Applications digikam Database-Media 4.8.0 openSUSE Linux RESOLVED FIXED NOR normal --- 0 dev digikam-bugs-null caulier.gilles metzpinguin peter017 7.2.0 0 oldest_to_newest 1503287 0 dev 2015-03-03 20:44:18 +0000 I tested this on digikam version 4.7.0 also, and got the same behaviour. I have 3 "root" albums. One on my local home directory and two on NFS shares. On my local album and on one NFS share I have the same sub album (which includes even more sub albums) with the same pictures. For example the sub albums have the name "2007". Only the sub album "2007" on the local album have pictures with tags. I renamed the sub album on the NFS share to "2007old". Than I moved the sub album "2007" from the local album to the album on the NFS share. After this album move, tags in sub album "2007" are lost. All operation are done inside digikam. So it seems that in this case digikam not moves the tags in the database. Btw. I use digikam with sqlite database. Reproducible: Always 1503319 1 caulier.gilles 2015-03-03 22:23:21 +0000 There is no reason to see this dysfunction. Can you try to reproduce the problem with last 4.8.0 ? 3.5.0 is very old now. Gilles Caulier 1504067 2 dev 2015-03-07 17:13:04 +0000 (In reply to Gilles Caulier from comment #1) > There is no reason to see this dysfunction. > > Can you try to reproduce the problem with last 4.8.0 ? 3.5.0 is very old now. > > Gilles Caulier 3.5.0 was the standard version on openSUSE 13.1. But as I wrote, I tested it with version 4.7.0 too and there was the same problem. I will see if I can find a RPM with version 4.8.0 to test with it. 1508867 3 dev 2015-04-04 10:23:23 +0000 I now tested it with version 4.8 and image tags are lost after I moved. I started digikam in a Konsole window and got some messages: digikam(28378)/digikam (core) Digikam::ImageInfo::fromLocationAlbumAndName: No itemShortInfo could be retrieved from the database for image "PICT0446.JPG" digikam(28378)/digikam (core) Digikam::ThumbnailCreator::createThumbnail: Cannot create thumbnail for "/home/.../Bilder/2010/Urlaub/PICT0670.JPG" 1508889 4 dev 2015-04-04 12:02:03 +0000 I have done a small video to show the bug. Unfortunately I can upload it as an attachment because of the file size limit on this site. But you can download it under the following link: https://www.dropbox.com/s/sr4tsbi7obbczjh/digikam.mkv?dl=0 The video is made with digikam 4.8.0. The album "Bilder" is on the local home directory. The album "Bilder Alle" is on a NFS directory. I don't know if its is important, the album "Bilder Nutzer" which is not involved in the operation is also on a NFS directory. The picture with the tag was on Bilder/2011/EBay and 2011 was moved to "Bilder Alle". After this, the tag was lost. 1535453 5 peter017 2015-08-06 20:41:36 +0000 I have a similar problem here (not NFS storage, though). I moved an album containing 1124 tagged pictures from one parent album to another. The operation took a long time (about 15 minutes). After this, 30 pictures among those have no more tags. The other pictures kept their tags. My database engine is SQLite. Digikam version is 4.8.0. I remember this also happened with some previous version(s) of digikam. I use the official Digikam RPM of Mageia 5. 1608573 6 caulier.gilles 2016-07-16 12:46:53 +0000 Can you reproduce this dysfunction with digiKam 5.0.0 ? Gilles Caulier 1642417 7 caulier.gilles 2016-11-29 11:17:40 +0000 Can you reproduce the problem using digiKam Linux AppImage bundle ? The last bundle is available at this url: https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM Gilles Caulier 1948212 8 caulier.gilles 2020-08-02 14:45:55 +0000 digiKam 7.0.0 stable release is now published: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Best regards Gilles Caulier 1955345 9 dev 2020-09-05 19:06:25 +0000 I just tested this behavior with digikam 6.4.0 and 7.0.0 (appimage) again and can't reproduce it anymore. So in my opinion this bug can be closed. 1955354 10 metzpinguin 2020-09-05 20:08:37 +0000 Thanks for the feedback, I close the bug.