Version: 0.8.0 (using KDE KDE 3.4.2) Installed from: SuSE RPMs Compiler: gcc 3.3.5 OS: Linux I just tried to run digikam 0.8 (svn vers from 2005/08/05) on my home system (suse9.3 with kde 3.4.2). On another mostly identical system with only some photos it works fine. However on my home system there seems to be trouble with some images. When I start digikam it starts scanning items. I gets to 18% and there it stops using 100% CPU time. An strace on digikam shows the following when it stops. At this point nothing else happens: open("/home/family/photos/beate/Jahr.2003(1)/09(September)/img_0045.jpg", O_RDONLY) = 16 fstat64(16, {st_mode=S_IFREG|0664, st_size=1085807, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4218f000 read(16, "\377\330\377\341!\376Exif\0\0II*\0\10\0\0\0\t\0\17\1\2"..., 4096) = 4096 _llseek(16, 0, [0], SEEK_SET) = 0 read(16, "\377\330\377\341!\376Exif\0\0II*\0\10\0\0\0\t\0\17\1\2"..., 4096) = 4096 read(16, "\0\353T\27\17\0\205#\214\271`X\271\307\4\34c\25H\202\243"..., 4096) = 4096 read(16, "\270/f\235i\352\377\0\345\324{\262\324\3213\250X\320\222"..., 4096) = 4096 The image is 1085807 Bytes in size and I can open it without any problems using an image viewer. However digikam has problems here. It stops working, the "scan item" percentage does not increase not disk activity but using 100% CPU. I can stop it pressing CTRL-C, so it not really hangs but does something but what? Digikam 0.7 has no problems working with the very same photo root directory on the same system. Perhaps something with exif.The program exif on this image says: EXIF tags in 'img_0045.jpg' ('Intel' byte order): --------------------+---------------------------------------------------------- Tag |Value --------------------+---------------------------------------------------------- Hersteller |Canon Modell |Canon PowerShot A70 Orientierung |links - unten Auflösung in x-Richt|180,00 Auflösung in y-Richt|180,00 Maßeinheit der Auflö|Inch Datum und Uhrzeit |2003:09:20 21:22:54 YCbCr Positionierung|zentriert Kompression |JPEG Kompression Auflösung in x-Richt|180,00 Auflösung in y-Richt|180,00 Maßeinheit der Auflö|Inch Belichtungszeit |1/60 sec. FNumber |f/2,8 Exif Version |Exif Version 2.2 Datum und Uhrzeit (o|2003:09:20 21:22:54 Datum und Uhrzeit (d|2003:09:20 21:22:54 ComponentsConfigurat|Y Cb Cr - Compressed Bits per |3,00 Shutter speed |189/32 sec. (APEX: 7) Aperture |f/2,8 Exposure Bias |0,0 MaxApertureValue |2,97 Metering Mode |Pattern Blitz |Flash fired, auto mode, red-eye reduction mode Focal Length |5,4 mm Anmerkungen des Hers|574 Byte(s) unbekannte Daten Anmerkung des Nutzer| FlashPixVersion |FlashPix Version 1.0 Color Space |sRGB PixelXDimension |2048 PixelYDimension |1536 Focal Plane x-Resolu|9846,15 Focal Plane y-Resolu|9846,15 Focal Plane Resoluti|Inch Sensing Method |One-chip color area sensor Dateiquelle |DSC Custom Rendered |Normal process Belichtungsart |Automatische Belichtungzeit White Balance |Auto white balance Digital Zoom Ratio |1,00 Scene Capture Type |Standard InteroperabilityInde|R98 InteroperabilityVers| RelatedImageWidth |2048 RelatedImageLength |1536 --------------------+---------------------------------------------------------- EXIF data contains a thumbnail (6639 bytes).
I wonder if it is the ß in the exif-info ;-) Please send an example image to us, so I can check.
I do not think its the "ß" because this german umlaut is only in the tag description not in the tag value. But the tag description is generated by the program exif I used to extract the exif data with german locale, so its not part of the jpg file itself.
I have exactly the same problem with a picture of mine. Its a small version of a normal picture, the normal picture works fine. It has only those exif-datas: Abmessung: 169 x 250 Pixel Farmodus: Farbe Blitz benutzt?: Nein JPEG-Prozess: Baseline Due to the privat nature of the picture, a cant send it to the list, but if you tell me what to do, i could investigate further
As I am unable to reproduce this, I can not fix it. So I'll leave this bug open now, just to gather votes I guess.
Received a sample image. The behaviour is now reproducable.
SVN commit 443276 by toma: This fixes an endless loop in the scanning of images. Continue was called without updating a first, so it arrives again at the same continue. BUG: 110214 M +8 -2 jpegmetadata.cpp --- trunk/extragear/graphics/digikam/libs/jpegutils/jpegmetadata.cpp #443275:443276 @@ -84,7 +84,10 @@ if (marker->marker == M_COM) { if (!marker->data || !marker->data_length) + { + marker=marker->next; continue; + } comments = QString::fromAscii((const char*)marker->data, marker->data_length); @@ -94,17 +97,20 @@ KExifData exifData; if (!exifData.readFromData((char*)marker->data, marker->data_length)) + { + marker=marker->next; continue; + } datetime = exifData.getExifDateTime(); } marker = marker->next; } - + jpeg_destroy_decompress(&srcinfo); - fclose(input_file); + fclose(input_file); } }
Not reproducible with digiKam 7.3.0 and Exiv2 0.27.4