digiKam "broke" - digiKam/GIMP issue?

[Elle Stone-2]

A couple days ago I had digiKam running while also running GIMP 2.9. I
saved a GIMP file to disk, to a folder that digiKam monitors. Saving the
GIMP file to disk seemed to be taking a very long time, with one CPU
core running at 100%.

But checking htop, it turned out to be digiKam that was occupying the
CPU core, not GIMP. So I (tried to) close digiKam. The digiKam UI closed
but the digiKam process was still running, so I ended up killing the
digiKam process using htop.

I tried to reproduce the issue, but couldn't trigger the same sequence
of events.

Today I triggered the same sequence of events. Except this time digiKam
seemed broken. It hung at 97% in the progress bar and never displayed
the image thumbnails, rendering digiKam unuseable. And it occupied 100%
of one CPU core. Restarting digiKam didn't help, and neither did
restarting the computer or recompiling/updating digiKam.

I run Gentoo Linux. Here's the component information:

digiKam version 4.14.0
CPU cores: 8
Demosaic GPL2 pack support: Yes
Demosaic GPL3 pack support: Yes
Exiv2 can write to Jp2: Yes
Exiv2 can write to Jpeg: Yes
Exiv2 can write to Pgf: Yes
Exiv2 can write to Png: Yes
Exiv2 can write to Tiff: Yes
Exiv2 supports XMP metadata: Yes
LibCImg: 130
LibEigen: 3.2.8
LibExiv2: 0.25
LibJPEG: 62
LibJasper: 1.900.1
LibKDE: 4.14.15
LibKExiv2: 2.3.2
LibKGeoMap: 3.1.0
LibKdcraw: 2.4.2
LibLCMS: 2070
LibLensFun: 0.3.1-0
LibLqr support: yes
LibPGF: 6.12.27
LibPNG: 1.6.19
LibQt: 4.8.6
LibRaw: 0.16.0
LibTIFF: LIBTIFF, Version 4.0.3 Copyright (c) 1988-1996 Sam Leffler
Copyright (c) 1991-1996 Silicon Graphics, Inc.
Marble Widget: 0.19.2 (stable release)
Parallelized demosaicing: Yes
RawSpeed codec support: No
Baloo support: no
Database backend: QSQLITE
Kdepimlibs support: no
Kipi-Plugins: 4.12.0
LibGphoto2 support: no
LibKface: 3.5.1
LibKipi: 2.1.0
LibOpenCV: 3.1.0
Sqlite2 support: no

I had a similar and probably the exact same issue with some GIMP 2.8 XCF
files awhile back (maybe a couple of years ago). So "something" about
some GIMP files seems to make digiKam very unhappy.

Moving the last-saved GIMP file to a folder that's not monitored by
digiKam allowed digiKam to start and run without any issues.

The GIMP file in question is 2.0GB, so I can't send it along as a test
file. But if it's the same problem as a couple of years ago, it also
sometimes happens with very small GIMP files.

As a test I modified the problem XCF file (removed two layers) and saved
it back to the digiKam-monitored folder, and digiKam had no issues with
it. But "undoing" the change in GIMP and resaving the file triggered the
digiKam issue.

Anyone have any idea why some GIMP XCF files cause issues with digiKam?

Best,
Elle
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

The only w

2016-03-09 18:42 GMT+01:00 Elle Stone <[hidden email]>:

A couple days ago I had digiKam running while also running GIMP 2.9. I saved a GIMP file to disk, to a folder that digiKam monitors. Saving the GIMP file to disk seemed to be taking a very long time, with one CPU core running at 100%.

But checking htop, it turned out to be digiKam that was occupying the CPU core, not GIMP. So I (tried to) close digiKam. The digiKam UI closed but the digiKam process was still running, so I ended up killing the digiKam process using htop.

I tried to reproduce the issue, but couldn't trigger the same sequence of events.

Today I triggered the same sequence of events. Except this time digiKam seemed broken. It hung at 97% in the progress bar and never displayed the image thumbnails, rendering digiKam unuseable. And it occupied 100% of one CPU core. Restarting digiKam didn't help, and neither did restarting the computer or recompiling/updating digiKam.

I run Gentoo Linux. Here's the component information:

digiKam version 4.14.0
CPU cores: 8
Demosaic GPL2 pack support: Yes
Demosaic GPL3 pack support: Yes
Exiv2 can write to Jp2: Yes
Exiv2 can write to Jpeg: Yes
Exiv2 can write to Pgf: Yes
Exiv2 can write to Png: Yes
Exiv2 can write to Tiff: Yes
Exiv2 supports XMP metadata: Yes
LibCImg: 130
LibEigen: 3.2.8
LibExiv2: 0.25
LibJPEG: 62
LibJasper: 1.900.1
LibKDE: 4.14.15
LibKExiv2: 2.3.2
LibKGeoMap: 3.1.0
LibKdcraw: 2.4.2
LibLCMS: 2070
LibLensFun: 0.3.1-0
LibLqr support: yes
LibPGF: 6.12.27
LibPNG: 1.6.19
LibQt: 4.8.6
LibRaw: 0.16.0
LibTIFF: LIBTIFF, Version 4.0.3 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc.
Marble Widget: 0.19.2 (stable release)
Parallelized demosaicing: Yes
RawSpeed codec support: No
Baloo support: no
Database backend: QSQLITE
Kdepimlibs support: no
Kipi-Plugins: 4.12.0
LibGphoto2 support: no
LibKface: 3.5.1
LibKipi: 2.1.0
LibOpenCV: 3.1.0
Sqlite2 support: no

I had a similar and probably the exact same issue with some GIMP 2.8 XCF files awhile back (maybe a couple of years ago). So "something" about some GIMP files seems to make digiKam very unhappy.

Moving the last-saved GIMP file to a folder that's not monitored by digiKam allowed digiKam to start and run without any issues.

The GIMP file in question is 2.0GB, so I can't send it along as a test file. But if it's the same problem as a couple of years ago, it also sometimes happens with very small GIMP files.

As a test I modified the problem XCF file (removed two layers) and saved it back to the digiKam-monitored folder, and digiKam had no issues with it. But "undoing" the change in GIMP and resaving the file triggered the digiKam issue.

Anyone have any idea why some GIMP XCF files cause issues with digiKam?

Best,
Elle
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

The only simple way to investigate is to see the debug trace on the console.

Another possibility is to share this 20Gb XCF file to try to reproduce the problem.

Gilles Caulier

2016-03-09 18:42 GMT+01:00 Elle Stone <[hidden email]>:

A couple days ago I had digiKam running while also running GIMP 2.9. I saved a GIMP file to disk, to a folder that digiKam monitors. Saving the GIMP file to disk seemed to be taking a very long time, with one CPU core running at 100%.

But checking htop, it turned out to be digiKam that was occupying the CPU core, not GIMP. So I (tried to) close digiKam. The digiKam UI closed but the digiKam process was still running, so I ended up killing the digiKam process using htop.

I tried to reproduce the issue, but couldn't trigger the same sequence of events.

Today I triggered the same sequence of events. Except this time digiKam seemed broken. It hung at 97% in the progress bar and never displayed the image thumbnails, rendering digiKam unuseable. And it occupied 100% of one CPU core. Restarting digiKam didn't help, and neither did restarting the computer or recompiling/updating digiKam.

I run Gentoo Linux. Here's the component information:

digiKam version 4.14.0
CPU cores: 8
Demosaic GPL2 pack support: Yes
Demosaic GPL3 pack support: Yes
Exiv2 can write to Jp2: Yes
Exiv2 can write to Jpeg: Yes
Exiv2 can write to Pgf: Yes
Exiv2 can write to Png: Yes
Exiv2 can write to Tiff: Yes
Exiv2 supports XMP metadata: Yes
LibCImg: 130
LibEigen: 3.2.8
LibExiv2: 0.25
LibJPEG: 62
LibJasper: 1.900.1
LibKDE: 4.14.15
LibKExiv2: 2.3.2
LibKGeoMap: 3.1.0
LibKdcraw: 2.4.2
LibLCMS: 2070
LibLensFun: 0.3.1-0
LibLqr support: yes
LibPGF: 6.12.27
LibPNG: 1.6.19
LibQt: 4.8.6
LibRaw: 0.16.0
LibTIFF: LIBTIFF, Version 4.0.3 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc.
Marble Widget: 0.19.2 (stable release)
Parallelized demosaicing: Yes
RawSpeed codec support: No
Baloo support: no
Database backend: QSQLITE
Kdepimlibs support: no
Kipi-Plugins: 4.12.0
LibGphoto2 support: no
LibKface: 3.5.1
LibKipi: 2.1.0
LibOpenCV: 3.1.0
Sqlite2 support: no

I had a similar and probably the exact same issue with some GIMP 2.8 XCF files awhile back (maybe a couple of years ago). So "something" about some GIMP files seems to make digiKam very unhappy.

Moving the last-saved GIMP file to a folder that's not monitored by digiKam allowed digiKam to start and run without any issues.

The GIMP file in question is 2.0GB, so I can't send it along as a test file. But if it's the same problem as a couple of years ago, it also sometimes happens with very small GIMP files.

As a test I modified the problem XCF file (removed two layers) and saved it back to the digiKam-monitored folder, and digiKam had no issues with it. But "undoing" the change in GIMP and resaving the file triggered the digiKam issue.

Anyone have any idea why some GIMP XCF files cause issues with digiKam?

Best,
Elle
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone-2]

On 03/09/2016 01:18 PM, Gilles Caulier wrote:
> The only simple way to investigate is to see the debug trace on the console.
>
> Another possibility is to share this 20Gb XCF file to try to reproduce
> the problem.

It's 2GB, not 20. If need be I'll try to upload it to a temporary link.

In the meantime, how do I make a debug trace on the console?

Best,
Elle


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

Debug trace : see "For hangs out or dysfunctions" section :

https://www.digikam.org/contrib

Gilles Caulier

2016-03-09 19:38 GMT+01:00 Elle Stone <[hidden email]>:

On 03/09/2016 01:18 PM, Gilles Caulier wrote:

The only simple way to investigate is to see the debug trace on the console.

Another possibility is to share this 20Gb XCF file to try to reproduce
the problem.

It's 2GB, not 20. If need be I'll try to upload it to a temporary link.

In the meantime, how do I make a debug trace on the console?

Best,
Elle


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone-2]

On 03/09/2016 02:28 PM, Gilles Caulier wrote:
> Debug trace : see "For hangs out or dysfunctions" section :
>
> https://www.digikam.org/contrib
>
> Gilles Caulier
>

gdb says "no debugging symbols found". I did compile digiKam with the
Gentoo "debug" use flag, but that apparently was the wrong thing to do
(https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces).

Anyway, fwiw, here's the (probably worthless) relevant gdb output, after
going through and removing all except the problem XCF file (so as to not
generate a ton of exceptions from digiKam not being able to read various
embedded exif information in XCF files):

digikam(14014)/KEXIV2: Cannot load metadata from file   (Error # 11 :
/home/elle/edit/digiKam/working/080801-1817-1576-2a.xcf: The file
contains data of an unknown image type
[New Thread 0x7fffceffd700 (LWP 14080)]
[New Thread 0x7fffb6ffd700 (LWP 14081)]
[New Thread 0x7fffcf7fe700 (LWP 14082)]
[Switching to Thread 0x7fffcf7fe700 (LWP 14082)]
Catchpoint 1 (exception thrown), 0x00007ffff1bee100 in __cxa_throw ()
from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
(gdb) bt
#0  0x00007ffff1bee100 in __cxa_throw () from
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
#1  0x00007ffff0f46cd5 in Exiv2::ImageFactory::open(std::string const&,
bool) () from /usr/lib64/libexiv2.so.14
#2  0x00007ffff769fa58 in KExiv2Iface::KExiv2::load(QString const&)
const () from /usr/lib64/libkexiv2.so.11
#3  0x00007ffff66f9d16 in Digikam::DMetadata::load(QString const&) const
() from /usr/lib64/libdigikamcore.so.4.14.0
#4  0x00007ffff66f9da2 in Digikam::DMetadata::DMetadata(QString const&)
() from /usr/lib64/libdigikamcore.so.4.14.0
#5  0x00007ffff67598e5 in
Digikam::ThumbnailCreator::createThumbnail(Digikam::ThumbnailInfo
const&, QRect const&) const ()
    from /usr/lib64/libdigikamcore.so.4.14.0
#6  0x00007ffff675df0a in
Digikam::ThumbnailCreator::load(Digikam::ThumbnailIdentifier const&,
QRect const&, bool) const ()
    from /usr/lib64/libdigikamcore.so.4.14.0
#7  0x00007ffff675eea0 in
Digikam::ThumbnailCreator::pregenerate(Digikam::ThumbnailIdentifier
const&) const () from /usr/lib64/libdigikamcore.so.4.14.0
#8  0x00007ffff676dbf0 in ?? () from /usr/lib64/libdigikamcore.so.4.14.0
#9  0x00007ffff6740dce in Digikam::LoadSaveThread::run() () from
/usr/lib64/libdigikamcore.so.4.14.0
#10 0x00007ffff677811e in
Digikam::DynamicThread::DynamicThreadPriv::run() () from
/usr/lib64/libdigikamcore.so.4.14.0
#11 0x00007ffff1f0ecd2 in ?? () from /usr/lib64/qt4/libQtCore.so.4
#12 0x00007ffff1f1b94f in ?? () from /usr/lib64/qt4/libQtCore.so.4
#13 0x00007ffff0135374 in start_thread () from /lib64/libpthread.so.0
#14 0x00007ffff13c244d in clone () from /lib64/libc.so.6
(gdb) continue
Continuing.


####### Now moving on to other files that throw exceptions but don't
cause digiKam to hang, I seem to have missed removing a few XCF files:


[Thread 0x7fffb6ffd700 (LWP 14081) exited]
digikam(14014)/KEXIV2: Cannot load metadata from file   (Error # 11 :
/home/elle/edit/digiKam/iiil/1427737696743614.xcf: The file contains
data of an unknown image type
Catchpoint 1 (exception thrown), 0x00007ffff1bee100 in __cxa_throw ()
from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
(gdb) bt
#0  0x00007ffff1bee100 in __cxa_throw () from
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
#1  0x00007ffff0f46cd5 in Exiv2::ImageFactory::open(std::string const&,
bool) () from /usr/lib64/libexiv2.so.14
#2  0x00007ffff76eb14e in
KExiv2Iface::KExiv2Previews::KExiv2Previews(QString const&) () from
/usr/lib64/libkexiv2.so.11
#3  0x00007ffff6759df1 in
Digikam::ThumbnailCreator::createThumbnail(Digikam::ThumbnailInfo
const&, QRect const&) const ()
    from /usr/lib64/libdigikamcore.so.4.14.0
#4  0x00007ffff675df0a in
Digikam::ThumbnailCreator::load(Digikam::ThumbnailIdentifier const&,
QRect const&, bool) const ()
    from /usr/lib64/libdigikamcore.so.4.14.0
#5  0x00007ffff675eea0 in
Digikam::ThumbnailCreator::pregenerate(Digikam::ThumbnailIdentifier
const&) const () from /usr/lib64/libdigikamcore.so.4.14.0
#6  0x00007ffff676dbf0 in ?? () from /usr/lib64/libdigikamcore.so.4.14.0
#7  0x00007ffff6740dce in Digikam::LoadSaveThread::run() () from
/usr/lib64/libdigikamcore.so.4.14.0
#8  0x00007ffff677811e in
Digikam::DynamicThread::DynamicThreadPriv::run() () from
/usr/lib64/libdigikamcore.so.4.14.0
#9  0x00007ffff1f0ecd2 in ?? () from /usr/lib64/qt4/libQtCore.so.4
#10 0x00007ffff1f1b94f in ?? () from /usr/lib64/qt4/libQtCore.so.4
#11 0x00007ffff0135374 in start_thread () from /lib64/libpthread.so.0
#12 0x00007ffff13c244d in clone () from /lib64/libc.so.6
(gdb) continue

and etc.

Best,
Elle

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

Well, it's simple : the probblem is in Exiv2 shared library which have some problem to read XCF file.

You use Exiv2 0.25. 

Please report this problem to Exiv2 bugzilla.

Gilles Caulier

2016-03-10 0:32 GMT+01:00 Elle Stone <[hidden email]>:

On 03/09/2016 02:28 PM, Gilles Caulier wrote:

Debug trace : see "For hangs out or dysfunctions" section :

https://www.digikam.org/contrib

Gilles Caulier

gdb says "no debugging symbols found". I did compile digiKam with the Gentoo "debug" use flag, but that apparently was the wrong thing to do (https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces).

Anyway, fwiw, here's the (probably worthless) relevant gdb output, after going through and removing all except the problem XCF file (so as to not generate a ton of exceptions from digiKam not being able to read various embedded exif information in XCF files):

digikam(14014)/KEXIV2: Cannot load metadata from file   (Error # 11 : /home/elle/edit/digiKam/working/080801-1817-1576-2a.xcf: The file contains data of an unknown image type
[New Thread 0x7fffceffd700 (LWP 14080)]
[New Thread 0x7fffb6ffd700 (LWP 14081)]
[New Thread 0x7fffcf7fe700 (LWP 14082)]
[Switching to Thread 0x7fffcf7fe700 (LWP 14082)]
Catchpoint 1 (exception thrown), 0x00007ffff1bee100 in __cxa_throw () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
(gdb) bt
#0  0x00007ffff1bee100 in __cxa_throw () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
#1  0x00007ffff0f46cd5 in Exiv2::ImageFactory::open(std::string const&, bool) () from /usr/lib64/libexiv2.so.14
#2  0x00007ffff769fa58 in KExiv2Iface::KExiv2::load(QString const&) const () from /usr/lib64/libkexiv2.so.11
#3  0x00007ffff66f9d16 in Digikam::DMetadata::load(QString const&) const () from /usr/lib64/libdigikamcore.so.4.14.0
#4  0x00007ffff66f9da2 in Digikam::DMetadata::DMetadata(QString const&) () from /usr/lib64/libdigikamcore.so.4.14.0
#5  0x00007ffff67598e5 in Digikam::ThumbnailCreator::createThumbnail(Digikam::ThumbnailInfo const&, QRect const&) const ()
   from /usr/lib64/libdigikamcore.so.4.14.0
#6  0x00007ffff675df0a in Digikam::ThumbnailCreator::load(Digikam::ThumbnailIdentifier const&, QRect const&, bool) const ()
   from /usr/lib64/libdigikamcore.so.4.14.0
#7  0x00007ffff675eea0 in Digikam::ThumbnailCreator::pregenerate(Digikam::ThumbnailIdentifier const&) const () from /usr/lib64/libdigikamcore.so.4.14.0
#8  0x00007ffff676dbf0 in ?? () from /usr/lib64/libdigikamcore.so.4.14.0
#9  0x00007ffff6740dce in Digikam::LoadSaveThread::run() () from /usr/lib64/libdigikamcore.so.4.14.0
#10 0x00007ffff677811e in Digikam::DynamicThread::DynamicThreadPriv::run() () from /usr/lib64/libdigikamcore.so.4.14.0
#11 0x00007ffff1f0ecd2 in ?? () from /usr/lib64/qt4/libQtCore.so.4
#12 0x00007ffff1f1b94f in ?? () from /usr/lib64/qt4/libQtCore.so.4
#13 0x00007ffff0135374 in start_thread () from /lib64/libpthread.so.0
#14 0x00007ffff13c244d in clone () from /lib64/libc.so.6
(gdb) continue
Continuing.


####### Now moving on to other files that throw exceptions but don't cause digiKam to hang, I seem to have missed removing a few XCF files:


[Thread 0x7fffb6ffd700 (LWP 14081) exited]
digikam(14014)/KEXIV2: Cannot load metadata from file   (Error # 11 : /home/elle/edit/digiKam/iiil/1427737696743614.xcf: The file contains data of an unknown image type
Catchpoint 1 (exception thrown), 0x00007ffff1bee100 in __cxa_throw () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
(gdb) bt
#0  0x00007ffff1bee100 in __cxa_throw () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
#1  0x00007ffff0f46cd5 in Exiv2::ImageFactory::open(std::string const&, bool) () from /usr/lib64/libexiv2.so.14
#2  0x00007ffff76eb14e in KExiv2Iface::KExiv2Previews::KExiv2Previews(QString const&) () from /usr/lib64/libkexiv2.so.11
#3  0x00007ffff6759df1 in Digikam::ThumbnailCreator::createThumbnail(Digikam::ThumbnailInfo const&, QRect const&) const ()
   from /usr/lib64/libdigikamcore.so.4.14.0
#4  0x00007ffff675df0a in Digikam::ThumbnailCreator::load(Digikam::ThumbnailIdentifier const&, QRect const&, bool) const ()
   from /usr/lib64/libdigikamcore.so.4.14.0
#5  0x00007ffff675eea0 in Digikam::ThumbnailCreator::pregenerate(Digikam::ThumbnailIdentifier const&) const () from /usr/lib64/libdigikamcore.so.4.14.0
#6  0x00007ffff676dbf0 in ?? () from /usr/lib64/libdigikamcore.so.4.14.0
#7  0x00007ffff6740dce in Digikam::LoadSaveThread::run() () from /usr/lib64/libdigikamcore.so.4.14.0
#8  0x00007ffff677811e in Digikam::DynamicThread::DynamicThreadPriv::run() () from /usr/lib64/libdigikamcore.so.4.14.0
#9  0x00007ffff1f0ecd2 in ?? () from /usr/lib64/qt4/libQtCore.so.4
#10 0x00007ffff1f1b94f in ?? () from /usr/lib64/qt4/libQtCore.so.4
#11 0x00007ffff0135374 in start_thread () from /lib64/libpthread.so.0
#12 0x00007ffff13c244d in clone () from /lib64/libc.so.6
(gdb) continue

and etc.

Best,
Elle

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone-2]

On 03/09/2016 07:11 PM, Gilles Caulier wrote:
> Well, it's simple : the probblem is in Exiv2 shared library which have
> some problem to read XCF file.
>
> You use Exiv2 0.25.
>
> Please report this problem to Exiv2 bugzilla.
>
> Gilles Caulier

 From the command line, exiv2 seems to have the same problem with *all*
the XCF files that I've tried it on, reporting as follows:

exiv2 unique-colors.xcf
Exiv2 exception in print action for file unique-colors.xcf:
 

unique-colors.xcf: The file contains data of an unknown image type

However, only a very few XCF files cause digiKam to stop functioning.

Is there a way to tell digiKam to not read the metadata from XCF files?

I'm not using digiKam to store metadata in an XCF file, and I'd just as
soon digiKam not bother trying to read the metadata in the XCF file (I
wish there were an option to tell GIMP to not store metadata in an XCF
file, but that's another issue).

Best,
Elle

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

2016-03-10 2:45 GMT+01:00 Elle Stone <[hidden email]>:

On 03/09/2016 07:11 PM, Gilles Caulier wrote:

Well, it's simple : the probblem is in Exiv2 shared library which have
some problem to read XCF file.

You use Exiv2 0.25.

Please report this problem to Exiv2 bugzilla.

Gilles Caulier

From the command line, exiv2 seems to have the same problem with *all* the XCF files that I've tried it on, reporting as follows:

exiv2 unique-colors.xcf
Exiv2 exception in print action for file unique-colors.xcf:

unique-colors.xcf: The file contains data of an unknown image type

However, only a very few XCF files cause digiKam to stop functioning.

Is there a way to tell digiKam to not read the metadata from XCF files?

No currently. The only way is to hard code a simple rule to ignore XCF type mime.

Gilles Caulier

I'm not using digiKam to store metadata in an XCF file, and I'd just as soon digiKam not bother trying to read the metadata in the XCF file (I wish there were an option to tell GIMP to not store metadata in an XCF file, but that's another issue).

Best,
Elle

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users