Bug 306782 - Rotating several times quickly corrupts images
Summary: Rotating several times quickly corrupts images
Alias: None
Product: digikam
Classification: Unclassified
Component: Plugin-Bqm-Rotate (show other bugs)
Version: 3.0.0
Platform: openSUSE RPMs Linux
: NOR critical (vote)
Target Milestone: ---
Assignee: Digikam Developers
URL: http://www.asktoby.com/miscimages/dig...
Depends on:
Reported: 2012-09-14 09:18 UTC by Toby Newman
Modified: 2017-07-28 03:44 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.0.0


Note You need to log in before you can comment on or make changes to this bug.
Description Toby Newman 2012-09-14 09:18:29 UTC
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.:
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!
Comment 1 caulier.gilles 2012-09-14 09:24:09 UTC
It's probably fixed with last stable 2.9.0. Please update and try again.

Gilles Caulier
Comment 2 Toby Newman 2012-09-14 10:44:23 UTC
I will wait for 2.9 to make it to the OpenSUSE 12.2 repos.
Comment 3 Toby Newman 2012-10-30 21:29:07 UTC
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!
Comment 4 Toby Newman 2012-11-20 22:00:28 UTC
I have uploaded a 90sec screencast demonstrating this bug:
It seems very serious to me.
With just a few clicks I am able to corrupt a whole folder of images!
Comment 5 Marcel Wiesweg 2012-11-21 18:12:00 UTC
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?
Comment 6 Toby Newman 2012-11-26 20:30:35 UTC
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.
Comment 7 ondrej.vorel 2012-11-27 18:27:43 UTC
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.
Comment 8 Marcel Wiesweg 2012-12-03 20:50:10 UTC
The network aspect is interesting. Toby: Can you reproduce when photos lie on the local disk?
Comment 9 Toby Newman 2012-12-28 20:23:33 UTC
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.
Comment 10 caulier.gilles 2012-12-28 20:40:55 UTC
I use also a SSD drive here (ext4), and i cannot reproduce the problem...

Gilles Caulier
Comment 11 Christian L 2013-01-30 19:12:30 UTC
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. 

Comment 12 Toby Newman 2013-02-26 20:24:44 UTC
I have just rebuilt my system with Fedora, KDE 4.9.5 and digikam 2.9.0 and can report that this issue remains.
Comment 13 Toby Newman 2013-02-26 20:33:57 UTC
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)
Comment 14 caulier.gilles 2013-02-26 22:13:23 UTC

What's about to use 3.0.0 official release ?

Gilles Caulier
Comment 15 Toby Newman 2013-03-05 16:21:01 UTC
Is the below 3.0.0 RPM sufficiently recent to be suitable for testing?
I'd like to avoid installing from source if possible.
Comment 16 caulier.gilles 2013-03-05 17:44:52 UTC
yes it sound like...

Gilles Caulier
Comment 17 Przemysław Palacz 2013-05-07 19:22:03 UTC
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.
Comment 18 Ruth Alkema 2013-08-10 19:54:20 UTC
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.
Comment 19 Ruth Alkema 2013-08-10 20:06:03 UTC
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.
Comment 20 caulier.gilles 2013-11-25 12:11:37 UTC
Problem still present in 3.5.0 release ?

Gilles Caulier
Comment 21 Toby Newman 2013-11-25 14:51:00 UTC
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!