I can second this grave bug.
This would give a beta2 a bad taste cause album view is nearly unusable.
Any instructions to help debugging? Whenn running with valgrind I see nothing special:

kio (Slave): slave failed to connect to application pid=21545 protocol=digikamdates
==21459==
==21459== Conditional jump or move depends on uninitialised value(s)
==21459==    at 0x4C12A0E9: kDebugBackend(unsigned short, unsigned, char const*) (in /usr/kde/3.4/lib/libkdecore.so.4.2.0)
==21459==    by 0x4C12ADFE: kdbgstream::flush() (in /usr/kde/3.4/lib/libkdecore.so.4.2.0)
==21459==    by 0x1B9A7A30: endl(kdbgstream&) (in /usr/kde/3.4/lib/libdigikam.so.0.0.0)
==21459==    by 0x4C860287: KIO::Slave::timeout() (in /usr/kde/3.4/lib/libkio.so.4.2.0)
==21459==    by 0x4C863FC7: KIO::Slave::qt_invoke(int, QUObject*) (in /usr/kde/3.4/lib/libkio.so.4.2.0)
==21459==    by 0x4BB6CAC8: QObject::activate_signal(QConnectionList*, QUObject*) (qobject.cpp:2355)
==21459==    by 0x4BECFF8E: QSignal::signal(QVariant const&) (moc_qsignal.cpp:100)
==21459==    by 0x4BB8A255: QSignal::activate() (qsignal.cpp:212)
==21459==    by 0x4BB91C17: QSingleShotTimer::event(QEvent*) (qtimer.cpp:286)
==21459==    by 0x4BB09614: QApplication::internalNotify(QObject*, QEvent*) (qapplication.cpp:2635)
==21459==    by 0x4BB08938: QApplication::notify(QObject*, QEvent*) (qapplication.cpp:2358)
==21459==    by 0x4C113F34: KApplication::notify(QObject*, QEvent*) (in /usr/kde/3.4/lib/libkdecore.so.4.2.0)
==21459==
==21459== Conditional jump or move depends on uninitialised value(s)
==21459==    at 0x4C12A0EF: kDebugBackend(unsigned short, unsigned, char const*) (in /usr/kde/3.4/lib/libkdecore.so.4.2.0)
==21459==    by 0x4C12ADFE: kdbgstream::flush() (in /usr/kde/3.4/lib/libkdecore.so.4.2.0)
==21459==    by 0x1B9A7A30: endl(kdbgstream&) (in /usr/kde/3.4/lib/libdigikam.so.0.0.0)
==21459==    by 0x4C860287: KIO::Slave::timeout() (in /usr/kde/3.4/lib/libkio.so.4.2.0)
==21459==    by 0x4C863FC7: KIO::Slave::qt_invoke(int, QUObject*) (in /usr/kde/3.4/lib/libkio.so.4.2.0)
==21459==    by 0x4BB6CAC8: QObject::activate_signal(QConnectionList*, QUObject*) (qobject.cpp:2355)
==21459==    by 0x4BECFF8E: QSignal::signal(QVariant const&) (moc_qsignal.cpp:100)
==21459==    by 0x4BB8A255: QSignal::activate() (qsignal.cpp:212)
==21459==    by 0x4BB91C17: QSingleShotTimer::event(QEvent*) (qtimer.cpp:286)
==21459==    by 0x4BB09614: QApplication::internalNotify(QObject*, QEvent*) (qapplication.cpp:2635)
==21459==    by 0x4BB08938: QApplication::notify(QObject*, QEvent*) (qapplication.cpp:2358)
==21459==    by 0x4C113F34: KApplication::notify(QObject*, QEvent*) (in /usr/kde/3.4/lib/libkdecore.so.4.2.0)
kio (Slave): slave is slow... pid=21545 t=4
kio (KIOJob): Job::kill this=0x1c49dde8 ThumbnailJob m_progressId=0 quietly=true
kio (KIOJob): Job::kill this=0x1c545478 ThumbnailJob m_progressId=0 quietly=true
kio (KIOJob): Job::kill this=0x1c7984c0 ThumbnailJob m_progressId=0 quietly=true
kio (KIOJob): Job::kill this=0x1cb7f280 ThumbnailJob m_progressId=0 quietly=true
kio (KIOJob): Job::kill this=0x1c1fb1a8 ThumbnailJob m_progressId=0 quietly=true
kio (KIOJob): Job::kill this=0x1c2002a0 ThumbnailJob m_progressId=0 quietly=true
kio (KIOJob): Job::kill this=0x1c1e9370 ThumbnailJob m_progressId=0 quietly=true
kio (KIOJob): Job::kill this=0x1c7813b8 ThumbnailJob m_progressId=0 quietly=true
kio (KIOJob): Job::kill this=0x1c4de4f8 ThumbnailJob m_progressId=0 quietly=true
kio (KIOJob): Job::kill this=0x1c1f39a8 ThumbnailJob m_progressId=0 quietly=true
...and so on. But KIOJob is procecced randomly.


Bye

  Thorsten

-- 
gentoo, qt-copy, kde-svn 3.5 branch, extragear-graphics: 461537

does this happen when the thumbnails are being generated for the first time or all the time? 

(i can't reproduce this and a quick look through the code path doesn't indicate what could be causing this.)

This is all the time. I made a fresh install generating a new digikam database and delete digikams userconfig. But this did not make a change. Thumbnail generation is dead slowly.
Maybe an interaction with curred kde-libs (I use kde-svn). Does digikam use system thumbnail generation? Thumbnail in Konqi do work and cached thumnail are instant.
digiKams thumbnail do not work. You have to do scrolling selecting to force a redraw of a single thumbnail.

Bye

  Thorsten 

This happens always.

I'm seeing this 100% too.  I'm not a digikam developer, but I was planning on taking a look at this to see if I can track it down (or at least narrow it down some).

do all of you have kde svn trunk libs/components installed?

Yes, I'm running the 3.5 branch.

hmm.... looks like i might have found the problem. there was a recent change in 
the kio library:
http://websvn.kde.org/branches/KDE/3.5/kdelibs/kio/kio/job.cpp?rev=456969&sortby=date&r2=456969&r1=444172

the thumbnailer in digikam relied on the earlier behavior of the thumbnailjob 
object being deleted immediately on completion. i will have to see what can be
done about this

SVN commit 461900 by pahlibar:

in kdelibs 3.5, the default behavior of kio::job has
changed, the job is not immediately deleted on emitResult,
but scheduled for a deferred delete. since, we were relying
on the immediate delete behavior, it ended up causing the
loading of thumbnails to slow down or stop completely. correct
for new behavior.

can the bugreporters verify that this fixes the problem?
CCBUGS: 112467


 M  +3 -1      albumfolderview.cpp  
 M  +1 -5      imagedescedit.cpp  
 M  +3 -0      imagepropertiesexif.cpp  
 M  +3 -0      imagepropertiesgeneral.cpp  
 M  +3 -0      imagepropertieshistogram.cpp  
 M  +3 -0      pixmapmanager.cpp  
 M  +1 -1      syncjob.cpp  


--- trunk/extragear/graphics/digikam/digikam/albumfolderview.cpp #461899:461900
@@ -212,7 +212,9 @@
 
 AlbumFolderView::~AlbumFolderView()
 {
-    delete d->iconThumbJob;
+    if (d->iconThumbJob)
+        d->iconThumbJob->kill();
+
     delete d;
 }
 
--- trunk/extragear/graphics/digikam/digikam/imagedescedit.cpp #461899:461900
@@ -399,13 +399,9 @@
     if (!m_thumbJob.isNull())
     {
         m_thumbJob->kill();
+        m_thumbJob = 0;
     }
 
-    if (!m_thumbJob.isNull())
-    {
-        delete m_thumbJob;
-    }
-
     ImageInfo* info = m_currItem->imageInfo();
     KURL fileURL;
     fileURL.setPath(info->filePath());
--- trunk/extragear/graphics/digikam/digikam/imagepropertiesexif.cpp #461899:461900
@@ -87,7 +87,10 @@
 {
 
     if (!m_thumbJob.isNull())
+    {
         m_thumbJob->kill();
+        m_thumbJob = 0;
+    }
 
     m_thumbJob = new ThumbnailJob(url, 48, true, AlbumSettings::instance()->getExifRotate());
     
--- trunk/extragear/graphics/digikam/digikam/imagepropertiesgeneral.cpp #461899:461900
@@ -152,7 +152,10 @@
     // ------------------------------------------------------------------------------
 
     if (!m_thumbJob.isNull())
+    {
         m_thumbJob->kill();
+        m_thumbJob = 0;
+    }
     
     m_thumbJob = new ThumbnailJob(url, 128, true, AlbumSettings::instance()->getExifRotate());
     
--- trunk/extragear/graphics/digikam/digikam/imagepropertieshistogram.cpp #461899:461900
@@ -295,7 +295,10 @@
 void ImagePropertiesHistogram::setData(const KURL& url, uint* imageData, int imageWidth, int imageHeight)
 {
     if (!m_thumbJob.isNull())
+    {
         m_thumbJob->kill();
+        m_thumbJob = 0;
+    }
 
     m_thumbJob = new ThumbnailJob(url, 48, true, AlbumSettings::instance()->getExifRotate());
     
--- trunk/extragear/graphics/digikam/digikam/pixmapmanager.cpp #461899:461900
@@ -165,7 +165,10 @@
 void PixmapManager::slotCompleted()
 {
     if (!m_thumbJob.isNull())
+    {
         m_thumbJob->kill();
+        m_thumbJob = 0;
+    }
 
     AlbumIconItem* item = m_view->nextItemToThumbnail();
     if (!item)
--- trunk/extragear/graphics/digikam/digikam/syncjob.cpp #461899:461900
@@ -176,7 +176,7 @@
                 SLOT(slotLoadThumbnailFailed()));
 
         enter_loop();
-        delete job;
+        job->kill();
     }
     else
     {

Works for me now!  Thanks!

got an additional confirmation from  Rainer Endres