<div dir="ltr">The only simple way to investigate is to see the debug trace on the console.<div><br></div><div>Another possibility is to share this 20Gb XCF file to try to reproduce the problem.</div><div><br></div><div>Gilles Caulier</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-09 18:42 GMT+01:00 Elle Stone <span dir="ltr"><<a href="mailto:ellestone@ninedegreesbelow.com" target="_blank">ellestone@ninedegreesbelow.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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%.<br>
<br>
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.<br>
<br>
I tried to reproduce the issue, but couldn't trigger the same sequence of events.<br>
<br>
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.<br>
<br>
I run Gentoo Linux. Here's the component information:<br>
<br>
digiKam version 4.14.0<br>
CPU cores: 8<br>
Demosaic GPL2 pack support: Yes<br>
Demosaic GPL3 pack support: Yes<br>
Exiv2 can write to Jp2: Yes<br>
Exiv2 can write to Jpeg: Yes<br>
Exiv2 can write to Pgf: Yes<br>
Exiv2 can write to Png: Yes<br>
Exiv2 can write to Tiff: Yes<br>
Exiv2 supports XMP metadata: Yes<br>
LibCImg: 130<br>
LibEigen: 3.2.8<br>
LibExiv2: 0.25<br>
LibJPEG: 62<br>
LibJasper: 1.900.1<br>
LibKDE: 4.14.15<br>
LibKExiv2: 2.3.2<br>
LibKGeoMap: 3.1.0<br>
LibKdcraw: 2.4.2<br>
LibLCMS: 2070<br>
LibLensFun: 0.3.1-0<br>
LibLqr support: yes<br>
LibPGF: 6.12.27<br>
LibPNG: 1.6.19<br>
LibQt: 4.8.6<br>
LibRaw: 0.16.0<br>
LibTIFF: LIBTIFF, Version 4.0.3 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc.<br>
Marble Widget: 0.19.2 (stable release)<br>
Parallelized demosaicing: Yes<br>
RawSpeed codec support: No<br>
Baloo support: no<br>
Database backend: QSQLITE<br>
Kdepimlibs support: no<br>
Kipi-Plugins: 4.12.0<br>
LibGphoto2 support: no<br>
LibKface: 3.5.1<br>
LibKipi: 2.1.0<br>
LibOpenCV: 3.1.0<br>
Sqlite2 support: no<br>
<br>
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.<br>
<br>
Moving the last-saved GIMP file to a folder that's not monitored by digiKam allowed digiKam to start and run without any issues.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Anyone have any idea why some GIMP XCF files cause issues with digiKam?<br>
<br>
Best,<br>
Elle<br>
_______________________________________________<br>
Digikam-users mailing list<br>
<a href="mailto:Digikam-users@kde.org" target="_blank">Digikam-users@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/digikam-users" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/digikam-users</a><br>
</blockquote></div><br></div>