Bug 237357 - Thumbnail's album can't be displayed
Summary: Thumbnail's album can't be displayed
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Thumbs-Image (show other bugs)
Version: 1.2.0
Platform: unspecified Linux
: HI major
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-12 10:58 UTC by dc
Modified: 2012-06-27 10:16 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.2.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dc 2010-05-12 10:58:20 UTC
Version:           1.2.0 (using 4.4.2 (KDE 4.4.2), Kubuntu packages)
Compiler:          cc
OS:                Linux (i686) release 2.6.32-22-generic

Opening digikam 1.2.0, on a structure created with previous versions, shows a list of album... but doesn't display thumbnails.

Launching dgikam from a console outputs the following error message :

ThumbnailLoadThread::load: No thumbnail size specified. Refusing to load thumbnail.

Though, this error can be considered like a crash, as digikam is totally useless...

Daniel Cordey
Comment 1 caulier.gilles 2010-05-12 11:04:52 UTC
Marcel,

Another critical entry relevant of DB i think. I can reproduce here... but only with 1.3.0-svn, not 1.2.0...

Gilles Caulier
Comment 2 dc 2010-05-12 11:12:47 UTC
It would be nice to have a workaround until it's fixed in the final 1.3.0. 

I can reproduce this error on many different installations, but all with 1.2.0 (kubuntu 10.4). One of my colleague just installed digikam a few minytes ago... and has the problem too.

Daniel
Comment 3 dc 2010-05-12 16:14:44 UTC
I've got a hint... I converted one of my JPG image to a PNG format... and I can see it ! It seems that jpeg images can be made visible. What's wrong with jpeg ? Everything seems to work fine with jpeg images (Lonqueror, Dolphin, Gwneview...) except Digikam... Which constantly complains about an unknown default thumbnail size; despite having its value set in the configuration.

Daniel
Comment 4 caulier.gilles 2010-05-12 17:51:58 UTC
Sound like a problem with libjpeg which have been updated to 8.0 version recently. Perhaps your digiKam binary package have not been recompiled with this version.

Since a long time, libjpeg have been frozen to 6.b version (since more than 10 year now). with new release 7.0 and 8.0, binary compatibility have been broken.

The only way to check this point is to really recompile digiKam and co, including libkdcraw, libkexiv2, libkipi, and finaly kipi-plugins.

Look there for details :

http://www.digikam.org/drupal/download/KDE4

Gilles Caulier
Comment 5 Marcel Wiesweg 2010-05-12 17:55:57 UTC
Gilles: how do you reproduce this problem?

The "No thumbnail size specified. Refusing to load thumbnail." has been fixed some time ago in SVN. May be a red herring here.

dc: Only JPEG files affected?
Comment 6 caulier.gilles 2010-05-12 18:02:00 UTC
Marcel,

I remember to have seen this messages on the console, about the famous DB lock problem during first run...

Now, i confirm that it disappear.

Gilles
Comment 7 carina 2010-05-13 11:56:35 UTC
yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy







yo se wen i tach leytter box ,writer bord the yyyyyyy tyake over whayyyyyyyyyyyyyyyyyyyyy.somting i bad on compyuter, wen i open it no icon are there. so i can not se if there is problem, it yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyjust blu, bakgrund noting ather. i have tryyyyyyyyyyyyyyyyyyyyyyyyyyy
to reset computer . wen i tuch boter yes to restart,computer went black and stop to do comando, turn down,and start up agen.but noting are there. just superperformenc. eee storge boten kl and sos botom,ee pc -tips .yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy


yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
'yyyyyyyyyyyyyyyy




yyyyyyyyyyyyyyyyyyyyyyy
Comment 8 dc 2010-05-17 14:38:58 UTC
(In reply to comment #5)

> dc: Only JPEG files affected?

Yes, I confirm, only JPEG files are affected. I tried to convert a complete directory in PNG and eveything works fine then.

I can't really get the SVN/compile version on all affected systems as I don't have access to all of them. Users I know can barely launch KpackageKit...

Daniel
Comment 9 dc 2010-05-17 14:41:27 UTC
Marcel,

I don't know if you get mails from de bugs.kde.org (as I haven't seen your 
email in the cc list), but here is what I sent a few minutes ago :

Best regards

Daniel


In reply to comment #5)

> dc: Only JPEG files affected?

Yes, I confirm, only JPEG files are affected. I tried to convert a complete 
directory in PNG and eveything works fine then.

I can't really get the SVN/compile version on all affected systems as I don't 
have access to all of them. Users I know can barely launch KpackageKit...

Daniel
Comment 10 Marcel Wiesweg 2010-05-17 18:26:48 UTC
What is your libjpeg version?
As Gilles already said, I really suspect a libjpeg incompatibility/problem now that you say only JPEGs are affected.
Comment 11 dc 2010-05-18 15:41:12 UTC
> What is your libjpeg version?

Here are the two jpeg libraries installed on my system (and others).

libjpeg62                            6b-15ubuntu1
libopenjpeg2                         1.3+dfsg-4

> As Gilles already said, I really suspect a libjpeg incompatibility/problem 
> now that you say only JPEGs are affected.

I agree, but there is no error/warning at any time. Anyway, which version is really required ? Is this a bad package's dependency ?

Daniel
Comment 12 caulier.gilles 2010-05-18 15:44:29 UTC
OpenJPEG is JPEG2000 library. It's not standard JPEG lib.

libjpeg 6b is old version of the famous standard JPEG lib. Are you sure to not have 7.0 or 8.0 version installed on your computer ?

Gilles Caulier
Comment 13 dc 2010-05-18 16:38:22 UTC
(In reply to comment #12)
> OpenJPEG is JPEG2000 library. It's not standard JPEG lib.

OK, but it's installed anyway (certainly used by another application on my system).
 
> libjpeg 6b is old version of the famous standard JPEG lib. Are you sure to not
> have 7.0 or 8.0 version installed on your computer ?

Yes... That's rather old... But it's the only version I get with the standard repos for kubuntu 10.04.

I don't mind messing up my personal system with tarballs or SVN, but I can't really apply this to the other systems I manage. Well... requesting SVN software on production systems is not something I'd like to popularize... :-)

Daniel
Comment 14 dc 2010-05-20 12:59:39 UTC
Hi,

I've got a few hints... Since there is no error message, I kept thinking... I have thousands of pictures and digikam worked perfectly wit them before, besides, even though the ligjpeg is pretty old, an old lib should be able to handle old picture... No ? I wanted to prove that jpeg picture could still be handled by digikam, but I used a small trick ! I ran the following commands :

convert NIK_0037.JPG NIK_0037.jpeg
convert NIK_0037.JPG NIK_0037.jpg

And... digikam is able to display the thumbnails of NIK_0037.jpeg and NIK_0037.jpg !

It's not simply a matter of suffixes or lower case letters ! It's clearly related to the format of the file. All my Initial files are in format :

JPEG image data, EXIF standard 2.21

While, after using the conert command, they are in the following format :

JPEG image data, JFIF standard 1.01

This seems to imply that the current digikam/*lib* is unable to handle 'EXIF 2.21' inside a JPG file... The installed library on my system is :

libexif12

What do you think about this ?

Daniel
Comment 15 Thorben Kröger 2010-07-05 18:27:59 UTC
I am experiencing the same bug.

when I do 'convert image.jpg image_converted.jpg', the image I converted with image magick suddenly appears in the digikam album.

I also looked at 'identify -verbose image.jpg' and 'image_converted.jpg' and cannot see any meaningful differences:
"exif:ExifVersion: 48, 50, 50, 48" is the same for both images.

My system is a Gentoo ~amd64 system. The problem is still there with the latest digikam svn (I built the digikam-9999 from the kde git overlay). libkdcraw, libkexiv2, libkipi are from kde 4.5 release candidate.

I have the media-libs/jpeg-8b version installed.

ldd /usr/bin/digikam | grep jpeg
libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0x00007fb876632000)

Any other information that might be useful?
Comment 16 Thorben Kröger 2010-07-05 18:38:09 UTC
this is also seems to be relevant:
http://forums.gentoo.org/viewtopic-t-819004-highlight-digikam.html
Comment 17 caulier.gilles 2010-07-06 13:31:00 UTC
Thorben,

I also use all code from trunk. converting a JPEG file to another one work fine here. libjpeg 8a is also used there (Mandriva 2010.1)

Gilles Caulier
Comment 18 caulier.gilles 2010-10-06 15:27:04 UTC
Daniel,

Any news there ? Can you try to use digiKam 1.4.0 ?

Gilles Caulier
Comment 19 caulier.gilles 2010-11-24 09:08:49 UTC
digiKam 1.6.0 is out:

http://www.digikam.org/drupal/node/550

Please update and check if this entry still valid.

Thanks in advance

Gilles Caulier
Comment 20 dc 2010-12-22 16:31:37 UTC
On Wed,  6 Oct 2010 15:27:10 +0200 (CEST) - Gilles Caulier
<caulier.gilles@gmail.com> wrote:

> https://bugs.kde.org/show_bug.cgi?id=237357
>...
> Any news there ? Can you try to use digiKam 1.4.0 ?

Gilles, sorry for the delay... Yes, the probleme still exist with
digikam 1.4.0 and KDE 4.5.4.

Daniel
Comment 21 caulier.gilles 2010-12-22 16:34:17 UTC
... (:=)))... few day ago, digiKam 1.7.0 is out... please update to last stable and try again.

Best

Gilles Caulier
Comment 22 caulier.gilles 2011-07-06 11:25:40 UTC
We need feedback using a recent version. 2.0.0 RC is out, please test...

Thanks in advance

Gilles Caulier
Comment 23 Roger Larsson 2011-09-27 14:10:33 UTC
Never seen this bug before but got hurt by it this week.
digikam 1.9.0 (OpenSuSE Tumbleweed)

Dumping and comparing databases - no clue...
Recreating miniatures (simple) - can see the images processing - does not show up after processing...

Console output is a bit different - so this might be another problem.
IOSlaves does not start...

KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work 
QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in use, all queries will cease to work.
Time elapsed: 10 ms
Model: Time elapsed: 0 ms
TextureColorizer::setSeaFileLandFile: Time elapsed: 3 ms
Time elapsed: 0 ms
Model: Time elapsed: 0 ms
TextureColorizer::setSeaFileLandFile: Time elapsed: 3 ms
digikam(9896): couldn't create slave: "Kunde inte skapa I/O-slav:
Klauncher sa: Fel vid laddning av "kio_digikamdates".
" 
digikam(9896)/digikam (core) Digikam::AlbumManager::slotDatesJobResult: Failed to list dates 
digikam(9896): couldn't create slave: "Kunde inte skapa I/O-slav:
Klauncher sa: Fel vid laddning av "kio_digikamalbums".
" 
digikam(9896)/digikam (core) Digikam::ImageAlbumModel::slotResult: Failed to list url:  "Kunde inte starta processen Kunde inte skapa I/O-slav:
Klauncher sa: Fel vid laddning av "kio_digikamalbums".
." 
digikam(9896)/KIPI (general) Plugin_DebianScreenshots::setup: virtual void Plugin_DebianScreenshots::setup(QWidget*) 
Time elapsed: 1 ms
Model: Time elapsed: 0 ms
TextureColorizer::setSeaFileLandFile: Time elapsed: 3 ms
Time elapsed: 0 ms
Model: Time elapsed: 0 ms
TextureColorizer::setSeaFileLandFile: Time elapsed: 3 ms
Time elapsed: 1 ms
Model: Time elapsed: 0 ms
TextureColorizer::setSeaFileLandFile: Time elapsed: 3 ms
digikam(9896)/digikam (core) Digikam::StateSavingObjectPriv::getGroupFromObjectName: Object name for  Digikam::ImagePropertiesSideBarDB(0x46b6310)  is empty. Returning the default config group 
digikam(9896)/digikam (core) Digikam::StateSavingObjectPriv::getGroupFromObjectName: Object name for  Digikam::ImagePropertiesSideBarDB(0x4d163e0)  is empty. Returning the default config group
Comment 24 Roger Larsson 2011-09-28 10:51:50 UTC
my comment 23 was some other problem...
After logout/login cycle it works again.
Comment 25 caulier.gilles 2011-09-28 10:54:18 UTC
so, this file can be closed ?

Gilles Caulier
Comment 26 dc 2011-09-28 11:12:06 UTC
> --- Comment #25 from Gilles Caulier <caulier gilles gmail com>
> 2011-09-28 10:54:18 ---
> so, this file can be closed ?

Yes... all my old pictures are handled properly.

Thanks

Daniel