Bug 389690 - Updated image label and image is broken after metadata is written to file
Summary: Updated image label and image is broken after metadata is written to file
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Engine (show other bugs)
Version: 6.0.0
Platform: Ubuntu Linux
: NOR major
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-31 14:02 UTC by eben
Modified: 2021-04-25 10:04 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description eben 2018-01-31 14:02:14 UTC
I was adding metadata to a 7.2mb jpg file and after adding a label or star rating in digikam, digikam recreated the image to add the metadata to the image file. But the image was not saved properly and the new file was 1.5mb in size and missing just under half the pixel content (the bottom half of the image was just black with no data at all).

Steps to re create:
Change from thumbnail to preview.
Add label to image (I added the reject label).
Digikam save's the image and the image re-loads.
The bottom third of the image is missing and is gray or black depending on the application used to open the image.
I opened the image in another application to check and found that just under half the image was missing.

The same thing happen for 5 of my images before I found out. After I found out that digikam was not creating the images properly after adding metadata I then switched off this function in the settings so metadata is only written to sidecar files and the db.

I'm running digikam in quite on old computer (only 4gb RAM), and I noticed that most of the ram was in use when this happened, so maybe it just ran out of memory so only wrote part of the file? If this is the case would they be a way for digikam to just take longer and finish writing the data to file properly?

Environment
I'm running the latest 5.8.0 version using the diskimage from digikam.org on ubuntu 16.04 Lts. The system is up to date. I setup Digikam to use mariadb10 as backend and the images are accessed over smb from a nas, the network has jumbo frames enabled on all devices.
Comment 1 Maik Qualmann 2018-01-31 15:51:27 UTC
For JPEG files, I have never seen such a problem before. Is this problem to reproduce with all JPEG files or only with certain ones? Can you provide a test image and the output of the console? Sure your hard drive has no problems?

Maik
Comment 2 caulier.gilles 2018-01-31 18:11:13 UTC
It will help to :

1/ run digiKam in a GDB to have a backtrace.
2/ run digiKam in a console and report the debug statements.
3/ try to use current 5.9.0 pre-release Linux AppImage bundle to see if it's reproducible.

More details : https://www.digikam.org/contribute/

Gilles Caulier
Comment 3 caulier.gilles 2018-01-31 18:19:47 UTC
5.9.0 pre release AppImage bundle is here :

https://files.kde.org/digikam/

Gilles Caulier
Comment 4 eben 2018-02-02 05:05:02 UTC
First thanks for all the responses and sorry for my late reply.

Is this problem to reproduce with all JPEG files or only with certain ones?
I did not experiment yet, the system was meant to be a production environment.

Can you provide a test image and the output of the console? Sure your hard drive has no problems?
Here is a link to download the affected jpg's and the unaffected ones each side: https://cloud.zenquest.co/index.php/s/KfaQCGDPfts5Ybb

I can try running digikam 5.9.0 on a range of images and report back with the backtrace. However I don't even know what GDB stands for! What is the syntax for starting a digikam.diskimage from the console with GDB backtrace?
Many thanks
Comment 5 caulier.gilles 2018-02-02 05:19:18 UTC
digiKam AppImage and GDB : all is explained here :

https://files.kde.org/digikam/README.md

Gilles Caulier
Comment 6 eben 2018-02-02 08:26:20 UTC
Summery: writing metadata to the same jpg files on the local drive worked, but the images broke on the smb share from the nas.


I ran the digikam5.9.0 diskimage, I copied a set of the same photos from the naz to a local folder. Then after a few crashes trying to get digikam to add the local folder the photos loaded. I tried adding tags, labels, star ratings and rotating the images (I had already change digikams settings to write metadata to file). All seamed to work fine and the jpg images were undamaged. I then opened some other applications to use up all the RAM on the system in the same way it was when I had the problem before. However everything worked and the images were still ok. I did not test with other images of different types or from other cameras, etc as I was unable to replicate the problem in 5.9.0 with data on the local drive.

The nas and its drives are only 3 months old. The PC running ubuntu is about 6 years old but its internal drive is only 2 years old as it was upgraded to use an ssd. So the disks on both systems should be in good condition.
The jpg photos which broke however have been moved between quite a few drives and locations since 2013 when they were taken.
The console output can be accessed at the same location as the sample images: https://cloud.zenquest.co/index.php/s/KfaQCGDPfts5Ybb

------
Next I copied another set of the original files that are on the nas smb share to a new folder also on the nas and added them into digikam. I tried adding tags, metadata and star ratings. The problem came back and the images this time were sometimes completely empty of data and some had part or all of the data written. The console output file has also been uploaded.

I guess this might not be a digikam bug if this happens only when images are accessed over an smb share? Currently I'm not able to test if this problem still happens if I switch to an AFP or NFS share. The NAS is new and quite powerful with 8GB of ram.
Comment 7 caulier.gilles 2018-08-17 21:30:38 UTC
Can you reproduce the dysfunction using digiKam 6.0.0 pre-release bundle
available here :

https://files.kde.org/digikam/
Comment 8 caulier.gilles 2018-12-31 11:51:09 UTC
Can you reproduce the dysfunction using the last digiKam 6.0.0-beta3 just
released ?

https://www.digikam.org/news/2018-12-30-6.0.0-beta3_release_announcement/
Comment 9 eben 2019-01-08 09:27:49 UTC
Hi, sorry I had not done this sooner! I just tried to reproduce this using digiKam 6.0.0-beta3 and could not, everything worked as designed, thanks.