[Digikam-users] updated to DK4.3.0 but it crashes and cannot go back to 4.2.0...

Gian Paolo Sanino Vattier gpsanino at vtr.net
Fri Sep 19 00:48:58 BST 2014 

I am a big metadata modifier indeed. Each file has a lot of information
stored by the tagging tool. Very useful indeed in my job.
I removed any repo related to KDe and left only KDE: Current and 
Current: extra. I just checked for Digikam and the listed in my previous
report was the most up to date. Regarding libkexiv, it was not changed
neither.

I do have some video files inside the folders. I recall it was an issue
with phonon-backend-GStreamer, so I have by default VLC as backend to
prevent issues related to video previews on DK.

Yes the versioning can be confusing. As an example, libexiv2-13 is
available on the repo  obs://build.opensuse.org/multimedia:photo
it is not related to libkexiv2 but I did tried it. Nothing changed about
Digikam (it did with gimp and a couple of other apps) and it does not
replaced libexiv2-12. Both coexist and any attempt to delete libexiv2-12
to "force" using the latest version resulted in more than 600 packages
to be modified. So I left the two.

Since DK 4.3.0 seems to work fine on Carl and Peter's OpenSuSE boxes, it
would be interesting to know what package of libk**exiv2 and their
source repo you have.
Mine is libk**exiv2-11 (4.14.1-1.1) from KDE:Current

gps



On 09/18/2014 06:03 PM, Carl McGrath wrote:
>
> On 09/18/2014 03:38 PM, Gian Paolo Sanino wrote:
>> Hi Carl, I added the "KDE Current" repo instead of default and did a
>> full update (requested to downgrade some KDE packages).
>> Versions are now:
> As I understand it, these are not really 'downgrades'. Builds against
> 4.14.x have difference sequence of versions than 4.11.x or 4.12.y
>>     Digikam 4.3.0 (4.3.0-19.1-x86_64) - same version as Robert
>>     lib*k*exiv2-11 (4.14.1-1.1) - Carl is this your version? note the
>> "k" on the name to not confuse with next package.
> Yes, Guilles straightened me out :-)
>>     libexiv2-12 (0.23-9.3.1)
>>     Linux 3.11.10-21-desktop
>>     KDE now is Development Platform 4.14.1
>>
>> Logout and login just to be on the safe side, and here the results:
> I always logout/login when a significant KDE update comes along,
> otherwise /weird/ things can happen
>> - no more delay between greeting and interface. Great.
>> - It runs and opens some of the albums but it crashed again when
>> attempting to open a large album but also some small albums result
>> with the same crash.
>> - when run from konsole, the KDE Crash Handler shows up the same
>> backtrace output about the crash and also a new error type:
>>   digikam(5644)/KEXIV2: Cannot load metadata using Exiv2   (Error #
>> 11 :  /home/user/Videos/2010-01.mpg: The file contains data of an
>> unknown image type)
>>
> I opened all of my larget folders, no issues yet.
> I am not an aggressive metadata user or modifier.
> Are your folders videos or pics?
> I only have pics.
>> I agree with Gilles, that libkexiv2-11 (4.14.1-1.1) may be the source
>> of the problem. Needs to be upgraded but I have not find a RPM
>> corresponding to 2.3.2 nor able to compile a source version with
>> Gille's corrected file.
> Package version issues get sort of strange here, such as with an
> update to 4.14.1 looking like a downgrade from 4.11.x or 4.12.y.
> The opensuse packager for Digikam seems on top of things - check again
> tomorrow.
>>
>> Peter can you tell us what version of libkexiv2 do you have and its
>> source? (note the "k" n the package's name).
>>
>> gps
>>
>> On 09/18/2014 01:26 PM, Carl McGrath wrote:
>>> I run openSUSE 13.1 with KDE 4.14.1.
>>> Note that KDE 4.14.1 is in the "KDE Current" repo, not the 13.1
>>> default repo( whch is still KDE 4.11.x, I believe)
>>> Also note that DK 4.3.0 packages might be different in the default
>>> and "KDE Current" repos, particularly as a new version is being
>>> transitioned in.
>>>
>>> I just updated and Digikam  4.3.0 installed. It is version
>>> *4.3.0-18.1-x86_64*
>>>
>>> The package  *libexiv2-12 version 0.23-9.1.3 *is installed.
>>>
>>> So far, DK 4.3.0 opens, no crashes, etc. Seems OK, no extensive use
>>> as yet.
>>>
>>> Two changes(I believe), may be a bugs, or may be intentional:
>>> 1. When in Icon view, left-clicking on an icon opens preview mode(as
>>> in prior DK versions).
>>> When in Preview mode, there is no longer a small icon in upper left
>>> corner of preview to go back to icon mode.
>>> F3 does return Main view to Icon mode.
>>> Also, esc key  returns to Icon view.
>>> 2. When in Main window, Icon or Preview mode, right-clicking an Icon
>>> or Preview opens a drop down menu.
>>> What (I believe) was a menu item "Edit" [open the Digikam editor] is
>>> now "Open".
>>> Below "Open" is the Menu item "Open With", which opens a sub menu as
>>> before"
>>>
>>>
>>> On 09/18/2014 09:06 AM, Gilles Caulier wrote:
>>>> The crash is in libkexiv2, when preview are get from file to render
>>>> image on screen.
>>>>
>>>> I ready fixed this problem in source code.
>>>>
>>>> There is a report which still open about this topic, where i annotate
>>>> which simple commit i do to fix it in libkexiv2 :
>>>>
>>>> https://bugs.kde.org/show_bug.cgi?id=339144
>>>>
>>>> I upgraded libkexiv2 version to 2.3.2. If digiKam do not use this
>>>> version it will crash.
>>>>
>>>> digiKam have been released with this version of libkexiv2, but
>>>> packager drop libkexiv2 source code from tarball and use system based
>>>> library.
>>>>
>>>> The solution from packager is to backport my little commit in libkexiv2 package.
>>>>
>>>> Gilles Caulier
>>>>
>>>>
>>>>
>>>> 2014-09-18 14:36 GMT+02:00 Gian Paolo Sanino Vattier <gpsanino at vtr.net>:
>>>>> On 09/18/2014 02:15 AM, Remco Viëtor wrote:
>>>>>
>>>>> On Wednesday 17 September 2014 21:01:24 Gian Paolo Sanino Vattier wrote:
>>>>>
>>>>> Hi, I wonder if other may be experiencing the same as I do.
>>>>> I have auto-update enabled (I know, It should not), and today my DK
>>>>> 4.2.0 got updated to DK 4.3.0 (nice dog on the welcome picture btw).
>>>>> The problem is that this version crashes just a second after its process
>>>>> is 100% done (when thumbnails should show up). Repeating attempts
>>>>> produce the same result (crashed) but sometimes it reaches to show some
>>>>> thumbnails when it crushes.
>>>>>
>>>>> I checked the phonon backend and tried with Gstreamer as well as with
>>>>> VLC, with no difference.
>>>>>
>>>>> This is under OpenSuSE 13.1-x86_64 with KDE 4.11.5
>>>>>
>>>>> If I try running DK from the konsole, I get this:
>>>>>
>>>>> (...)
>>>>>
>>>>> I tried cleaning temp files as well as rebooting the PC, and checking
>>>>> updates with Yast, but nothing seems to solve the problem. I have no
>>>>> clue how to solve this DK4.3.0 crash, and I use DK for work and this is
>>>>> urgent for me, so I decided to go back to 4.2.0 however I have not been
>>>>> able. I only found it on the "Factory" repo, but it request for
>>>>> kdebase4-runtime  version >=4.14.0 but all my KDE is 4.11.5 (which is
>>>>> supposed to be up to date "stable" SuSE release). I may try to update to
>>>>> KDE 4.14.0 but this can result in total mess. I just do not understand
>>>>> why I cannot go back to the same version of DK 4.2.0 that I had just
>>>>> hours ago in thi very same KDE... maybe it is a SuSE packaging issue and
>>>>> not a DK issue, no idea.
>>>>>
>>>>> Anybody else with this issue? or any hint where to look for a solution?
>>>>> Thanks a lot
>>>>> gps
>>>>>
>>>>> I don't know how you use Digikam, and which part of the functionality you
>>>>> use, but you can go back to Digikam 3.5.0 (which is still in the Yast
>>>>> repositories for OpenSuse 13.1). I've been switching back and forth between
>>>>> 3.5 and 4.x a few times without problems, but back up the databases to be
>>>>> safe(r).
>>>>>
>>>>> Remco
>>>>>
>>>>>
>>>>> Hi Remco, I use Digikam a lot, mainly as a graphic database (filtering using
>>>>> the tagging tools). DK 4.2.0 was a great version for me since many
>>>>> improvements were achieved on the tagging side. No idea why DK4.2.0 on SuSE
>>>>> repos are requesting for KDE versions others than those on which it was
>>>>> running just fine.
>>>>> I was able to find on the Build Service a repo with DK 4.0.0 to downgrade
>>>>> from 4.3.0 and check the results. I use SpiderOak to backup constantly the
>>>>> database.
>>>>> I got it and regained immediate control over DK and my files as well...
>>>>> great.
>>>>>
>>>>> Then upgraded to 4.3.0 to double test, and again DK crashes but somehow now
>>>>> they take longer to crash. In fact, DK opens fine with the root Album
>>>>> selected as default and it can stay there fine until I select other Album
>>>>> (with images inside). That is when it starts rebuilding the thumbnails
>>>>> (recently I deleted my thumbnail.db file). The mystery is that it crashed
>>>>> almost randomly depending on what folder I select.  With some, it does the
>>>>> job fine but with others no hope, it crashed immediately. So, maybe this is
>>>>> something related to previews / thumbnails...
>>>>>
>>>>> When I restarted DK, I disabled both "include Album.. sub-tree" options
>>>>> under menu/View/. By disabling these features, I selected the same
>>>>> folder/album that always produced crashes and this time no crash. Then
>>>>> selected one of its sub-folders, with images inside and it crashed again...
>>>>>
>>>>> I went back to DK4.0.0 and regained control again. Since DK4.3.0 seems to
>>>>> crash when creating the new thumbnails of large number of images, I used
>>>>> 4.0.0 to rebuild all thumbnails. Then updated to 4.3.0 to see if it shows
>>>>> the albums without crashing, but I was not lucky. The folders starts showing
>>>>> up and DK crash. Some open fine and other not at all. It feels somehow like
>>>>> albums with larger number of files tend to crash more often than those with
>>>>> lower amount of files. It am not sure. But then, the thumbnail building
>>>>> process does not seem to be a key part of the problem... Another difference
>>>>> with DK4.3.0 is that after the welcoming frame closes (with the nice dog
>>>>> jumping) it takes about 15 seconds to open digikam's interface (DK4.2.0
>>>>> takes no time between the two).
>>>>>
>>>>> KDE Crash handler reports the event as : "Executable: digikam PID: 2876
>>>>> Signal: Segmentation fault (11)".
>>>>> and KDE backtrace report shows this:
>>>>>
>>>>> Application: digiKam (digikam), signal: Segmentation fault
>>>>>
>>>>> Using host libthread_db library "/lib64/libthread_db.so.1".
>>>>>
>>>>> [Current thread is 1 (Thread 0x7fdc3c95a940 (LWP 2876))]
>>>>>
>>>>>
>>>>> Thread 4 (Thread 0x7fdc15107700 (LWP 2877)):
>>>>>
>>>>> #0 0x00007fdc330000af in pthread_cond_wait@@GLIBC_2.3.2 () from
>>>>> /lib64/libpthread.so.0
>>>>>
>>>>> #1 0x00007fdc35e95b66 in QWaitCondition::wait(QMutex*, unsigned long) ()
>>>>> from /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #2 0x00000000005fe6ae in ?? ()
>>>>>
>>>>> #3 0x00007fdc35e9568f in ?? () from /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #4 0x00007fdc32ffc0db in start_thread () from /lib64/libpthread.so.0
>>>>>
>>>>> #5 0x00007fdc350ae58d in clone () from /lib64/libc.so.6
>>>>>
>>>>>
>>>>> Thread 3 (Thread 0x7fdc14906700 (LWP 2878)):
>>>>>
>>>>> #0 0x00007fdc2cbd2586 in ?? () from /usr/lib64/libglib-2.0.so.0
>>>>>
>>>>> #1 0x00007fdc2cbd270c in g_main_context_iteration () from
>>>>> /usr/lib64/libglib-2.0.so.0
>>>>>
>>>>> #2 0x00007fdc35fc1d76 in
>>>>> QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
>>>>> () from /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #3 0x00007fdc35f93d0f in
>>>>> QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from
>>>>> /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #4 0x00007fdc35f94005 in
>>>>> QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
>>>>> /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #5 0x00007fdc35e92fef in QThread::exec() () from /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #6 0x00007fdc35f75513 in ?? () from /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #7 0x00007fdc35e9568f in ?? () from /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #8 0x00007fdc32ffc0db in start_thread () from /lib64/libpthread.so.0
>>>>>
>>>>> #9 0x00007fdc350ae58d in clone () from /lib64/libc.so.6
>>>>>
>>>>>
>>>>> Thread 2 (Thread 0x7fdb83fff700 (LWP 2944)):
>>>>>
>>>>> [KCrash Handler]
>>>>>
>>>>> #5 0x00007fdc31e12075 in
>>>>> Exiv2::PreviewManager::getPreviewImage(Exiv2::PreviewProperties const&)
>>>>> const () from /usr/lib64/libexiv2.so.12
>>>>>
>>>>> #6 0x00007fdc3a66dcb2 in KExiv2Iface::KExiv2Previews::data(int) () from
>>>>> /usr/lib64/libkexiv2.so.11
>>>>>
>>>>> #7 0x00007fdc3a66df0b in KExiv2Iface::KExiv2Previews::image(int) () from
>>>>> /usr/lib64/libkexiv2.so.11
>>>>>
>>>>> #8 0x00007fdc39c6650d in
>>>>> Digikam::ThumbnailCreator::createThumbnail(Digikam::ThumbnailInfo const&,
>>>>> QRect const&) const () from /usr/lib64/libdigikamcore.so.4.3.0
>>>>>
>>>>> #9 0x00007fdc39c691a6 in Digikam::ThumbnailCreator::load(QString const&,
>>>>> QRect const&, bool) const () from /usr/lib64/libdigikamcore.so.4.3.0
>>>>>
>>>>> #10 0x00007fdc39c69af0 in Digikam::ThumbnailCreator::pregenerate(QString
>>>>> const&) const () from /usr/lib64/libdigikamcore.so.4.3.0
>>>>>
>>>>> #11 0x00007fdc39c784a0 in ?? () from /usr/lib64/libdigikamcore.so.4.3.0
>>>>>
>>>>> #12 0x00007fdc39c506c6 in Digikam::LoadSaveThread::run() () from
>>>>> /usr/lib64/libdigikamcore.so.4.3.0
>>>>>
>>>>> #13 0x00007fdc39c7e6be in Digikam::DynamicThread::DynamicThreadPriv::run()
>>>>> () from /usr/lib64/libdigikamcore.so.4.3.0
>>>>>
>>>>> #14 0x00007fdc35e8913e in ?? () from /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #15 0x00007fdc35e9568f in ?? () from /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #16 0x00007fdc32ffc0db in start_thread () from /lib64/libpthread.so.0
>>>>>
>>>>> #17 0x00007fdc350ae58d in clone () from /lib64/libc.so.6
>>>>>
>>>>>
>>>>> Thread 1 (Thread 0x7fdc3c95a940 (LWP 2876)):
>>>>>
>>>>> #0 0x00007fdc330000af in pthread_cond_wait@@GLIBC_2.3.2 () from
>>>>> /lib64/libpthread.so.0
>>>>>
>>>>> #1 0x00007fdc35e95b66 in QWaitCondition::wait(QMutex*, unsigned long) ()
>>>>> from /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #2 0x00007fdc35e88b52 in ?? () from /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #3 0x00007fdc35e89ef5 in QThreadPool::~QThreadPool() () from
>>>>> /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #4 0x00007fdc35e89f29 in QThreadPool::~QThreadPool() () from
>>>>> /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #5 0x00007fdc35fab658 in QObjectPrivate::deleteChildren() () from
>>>>> /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #6 0x00007fdc35fadbff in QObject::~QObject() () from
>>>>> /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #7 0x00007fdc39c7b847 in ?? () from /usr/lib64/libdigikamcore.so.4.3.0
>>>>>
>>>>> #8 0x00007fdc34fff059 in __run_exit_handlers () from /lib64/libc.so.6
>>>>>
>>>>> #9 0x00007fdc34fff0a5 in exit () from /lib64/libc.so.6
>>>>>
>>>>> #10 0x00007fdc36a0a298 in ?? () from /usr/lib64/libQtGui.so.4
>>>>>
>>>>> #11 0x00007fdc376b91a0 in KApplication::xioErrhandler(_XDisplay*) () from
>>>>> /usr/lib64/libkdeui.so.5
>>>>>
>>>>> #12 0x00007fdc3359d3fe in _XIOError () from /usr/lib64/libX11.so.6
>>>>>
>>>>> #13 0x00007fdc3359aded in _XEventsQueued () from /usr/lib64/libX11.so.6
>>>>>
>>>>> #14 0x00007fdc3358cddb in XEventsQueued () from /usr/lib64/libX11.so.6
>>>>>
>>>>> #15 0x00007fdc36a403ac in ?? () from /usr/lib64/libQtGui.so.4
>>>>>
>>>>> #16 0x00007fdc2cbd2081 in g_main_context_check () from
>>>>> /usr/lib64/libglib-2.0.so.0
>>>>>
>>>>> #17 0x00007fdc2cbd259b in ?? () from /usr/lib64/libglib-2.0.so.0
>>>>>
>>>>> #18 0x00007fdc2cbd270c in g_main_context_iteration () from
>>>>> /usr/lib64/libglib-2.0.so.0
>>>>>
>>>>> #19 0x00007fdc35fc1d55 in
>>>>> QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
>>>>> () from /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #20 0x00007fdc36a40936 in ?? () from /usr/lib64/libQtGui.so.4
>>>>>
>>>>> #21 0x00007fdc35f93d0f in
>>>>> QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from
>>>>> /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #22 0x00007fdc35f94005 in
>>>>> QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
>>>>> /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #23 0x00007fdc35f9913b in QCoreApplication::exec() () from
>>>>> /usr/lib64/libQtCore.so.4
>>>>>
>>>>> #24 0x000000000049f870 in ?? ()
>>>>>
>>>>> #25 0x00007fdc34fe8be5 in __libc_start_main () from /lib64/libc.so.6
>>>>>
>>>>> #26 0x00000000004a1ec1 in _start ()
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Digikam-users mailing list
>>>>> Digikam-users at kde.org
>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>
>>>> _______________________________________________
>>>> Digikam-users mailing list
>>>> Digikam-users at kde.org
>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>
>>>
>>>
>>> _______________________________________________
>>> Digikam-users mailing list
>>> Digikam-users at kde.org
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>
>>
>>
>> _______________________________________________
>> Digikam-users mailing list
>> Digikam-users at kde.org
>> https://mail.kde.org/mailman/listinfo/digikam-users
>
>
>
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20140918/5f68edf0/attachment.html>

More information about the Digikam-users mailing list