Rapid rotations via keyboard cause data loss Reproducible: Always Steps to Reproduce: 1) Select folder in "My Albums" 2) Multiselect several photos in the album preview window on right hand side 3) Rapidly execute a series of rotate commands via keyboard, e.g.: Ctrl-Shift-right Ctrl-Shift-right Ctrl-Shift-left Ctrl-Shift-right Ctrl-Shift-left 4) Images become corrupt. Actual Results: Some jpgs simply will no longer load, others load and are partially grey. Expected Results: It should have waited for each rotation to finish before starting the next. Possible to select many photos and do this, potentially causing a large loss of data!
It's probably fixed with last stable 2.9.0. Please update and try again. Gilles Caulier
I will wait for 2.9 to make it to the OpenSUSE 12.2 repos.
I'm now running Digikam version 3.0.0-beta3 and this bug is still present. It's possible to wipe out a whole directory of images with one stray click!
I have uploaded a 90sec screencast demonstrating this bug: http://www.youtube.com/watch?v=dzIYUSv8xbk It seems very serious to me. With just a few clicks I am able to corrupt a whole folder of images!
As you may imagine, we cannot reproduce this bug on our systems. Can you reproduce this with only one image (+ multiple commands), or a few (2-5) images? Are you compiling from source so that you could test a patch?
Thank you for looking at this. I cannot reproduce the error using just one image, but I am able to reproduce it by selecting just two images. I am not running from source. Other information that may be relevant: My digikam4.db file is on my local hard disk. My photo library is stored on my NAS, connected via gigabit LAN, and shared via SAMBA with write permissions.
I can confirm the same behavior in version 2.9.0 (running from gentoo stable portage). While rotating few selected thumbnails in "Thumbnails" section, some of them are corrupted. Sometimes results in 0 bytes size files, sometimes are the pictures demaged partialy. Partialy means that just few rows of pixels are visible, the rest is just gray area. Corruption rate is about 20%. Photos are stored on NFS drive, colection is registered as on network share drive in digikam settings. I have also try to copy them to iSCSI drive (whole system is running on iSCSI). Sorry, It's a diskless PC, and I don't have any free physical disk available for testing.
The network aspect is interesting. Toby: Can you reproduce when photos lie on the local disk?
Marcel, I can reproduce the issue when photos lie on the local disk, so we can rule out the network aspect. My local disk is an SSD, for what it's worth. Toby
I use also a SSD drive here (ext4), and i cannot reproduce the problem... Gilles Caulier
I can confirm what has been described above. When rotating multiple images (more than four or five) at a time (or in a fast sequence), one or two of the processed images get corrupted. However, this does not happen when rotating one after another in single steps. I am running version 2.9.0 (using kde plattform 4.9.2) on opensuse 12.2. I hope, we can identify the source soon. I am a committed digikam user and can hardly understand why this severe thing is happening. Chris
I have just rebuilt my system with Fedora, KDE 4.9.5 and digikam 2.9.0 and can report that this issue remains.
Tip: It is possible to hide the rotate command to reduce the risk of accidentally clicking it and corrupting photos: Settings/Configure Digikam/Album View/Show rotation overlay buttons (untick)
Toby, What's about to use 3.0.0 official release ? Gilles Caulier
Is the below 3.0.0 RPM sufficiently recent to be suitable for testing? http://rpmfind.net//linux/RPM/fedora/devel/rawhide/i386/d/digikam-3.0.0-1.fc19.i686.html I'd like to avoid installing from source if possible.
yes it sound like... Gilles Caulier
This bug is still present in version 3.1 (installed from Fedora rpm) For me it occurs when I'm selecting multiple images to rotate by 180 degrees - by rapidly clicking twice either rotate left or right by 90 degrees. From multiple images selected to rotate few are getting destroyed. This does not always happen, sometimes the same images are rotated correctly (fortunately I didn't move photos just copied them so I had the chance to try again). To me it looks like thread responsible for rotating is crashing before finishing the job.
I also have this problem, I just noticed that I have files named like JpegRotator-ga6350.digikamtempfile.jpg in the directory instead of the rotated file.
Another thing I just noticed, after rotating a lot of photos to the rotation as stored in exif, is that sometimes two pictures will be the same. So, say I rotated photos a,b,c and d, then after the batch finishes b and c are equal to b, and picture c is missing.
Problem still present in 3.5.0 release ? Gilles Caulier
Just tested in Digikam 3.5.0 Using KDE Development Platform 4.11.3 on Fedora 19 and issue is resolved. Well done and thank you!