Bug 315025

Summary:	0Byte sized files after using 2 actions in Batch Queue Manager
Product:	[Applications] digikam	Reporter:	Mike <mailto.mikes>
Component:	Plugin-Bqm-Convert	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	RESOLVED FIXED
Severity:	major	CC:	caulier.gilles
Priority:	NOR
Version:	3.0.0
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:	4.3.0
Sentry Crash Report:

Description Mike 2013-02-12 22:31:38 UTC

I tried to use batch queue Manager to do some modifications to about 40 jpgs / 12mpx size. After the jobs runs completely without errors the Digikam Browser shows an empty Image and the size was 0 byte.   I tried that with a new workflow... ( besides editing a workflow leads to a crash of digikam ) and with fewer pics and its always the same:  0byte sized pics ... 

Reproducible: Always

Steps to Reproduce:
1. mark some pictures in Digikam browser
2. Click Batch Queue Manager
3. Assign Actions "color Auto correction - exposure"
4. assign action "sharpen image - simple sharp" 
5. User "original album" as target - Rename File to file+"sometext"
6. run the queue
Actual Results:  
All modified files have the correct name and exist but they have 0 Byte size...so they are useless. 

Expected Results:  
Files should have a similar size then the original files with modifications from the batch.

Comment 1 caulier.gilles 2013-02-13 05:23:59 UTC

This only apply to JPEG ? What's about PNG or TIFF ?

Which libjpeg you use on your system. here, it's libjpeg 8, and there is no problem.

Do you use libjpeg-turbo ?

What do you see as debug trace on the console. Open a console run kdebugdialog and turn on digikam, KExiv2 space. After that, start digiKam.

Gilles Caulier

Comment 2 caulier.gilles 2013-02-13 05:34:21 UTC

Look like all is fine here :

http://www.flickr.com/photos/digikam/8470323584/sizes/l/in/photostream/

Gilles Caulier

Comment 3 Mike 2013-02-13 21:35:43 UTC

(In reply to comment #1)
> This only apply to JPEG ? What's about PNG or TIFF ?
> 
> Which libjpeg you use on your system. here, it's libjpeg 8, and there is no
> problem.
> 
> Do you use libjpeg-turbo ?
> 
> What do you see as debug trace on the console. Open a console run
> kdebugdialog and turn on digikam, KExiv2 space. After that, start digiKam.
> 
> Gilles Caulier

Hi Gilles,
I use following components - sorry that I forgot them to include in my initial post. 
Furthermore it works if I add a convert job to png or tiff.  

First here my components: 

digiKam version 3.0.0-rc
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
LibClapack: internal library
LibExiv2: 0.22
LibJPEG: 80
LibJasper: 1.900.1
LibKDE: 4.10.00
LibKExiv2: 2.3.0
LibKGeoMap: 2.0.0
LibKdcraw: 2.2.0
LibLCMS: 119
LibLensFun: external shared library
LibLqr: internal library
LibPGF: 6.12.27 - internal library
LibPNG: 1.2.46
LibQt: 4.8.2
LibRaw: 0.15.0-Beta1
LibTIFF: LIBTIFF, Version 3.9.5 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc.
Marble Widget: 0.12.2 (stable release)
Parallelized PGF codec: No
Parallelized demosaicing: No
RawSpeed codec support: No
Database backend: QSQLITE
Kipi-Plugins: 3.0.0-rc
LibGphoto2: 2.4.14
LibKface: 2.0.0
LibKipi: 2.0.0
LibOpenCV: 2.4.2
Libface: 0.2

heredigiKam version 3.0.0-rc
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
LibClapack: internal library
LibExiv2: 0.22
LibJPEG: 80
LibJasper: 1.900.1
LibKDE: 4.10.00
LibKExiv2: 2.3.0
LibKGeoMap: 2.0.0
LibKdcraw: 2.2.0
LibLCMS: 119
LibLensFun: external shared library
LibLqr: internal library
LibPGF: 6.12.27 - internal library
LibPNG: 1.2.46
LibQt: 4.8.2
LibRaw: 0.15.0-Beta1
LibTIFF: LIBTIFF, Version 3.9.5 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc.
Marble Widget: 0.12.2 (stable release)
Parallelized PGF codec: No
Parallelized demosaicing: No
RawSpeed codec support: No
Database backend: QSQLITE
Kipi-Plugins: 3.0.0-rc
LibGphoto2: 2.4.14
LibKface: 2.0.0
LibKipi: 2.0.0
LibOpenCV: 2.4.2
Libface: 0.2

Second here the output of kdebugdialog after activating "digikam" & "Kexiv2" :

SqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in use, all queries will cease to work.
digikam(4537) Phonon::KdePlatformPlugin::createBackend: using backend:  "GStreamer"

..thats all..!?   

Michael

Comment 4 caulier.gilles 2013-02-13 22:13:15 UTC

Sound like the problem is outside. Can you share some original JPEG files that you try to process in BQM, to see if i can reproduce the problem here ?

Gilles Caulier

Comment 5 Mike 2013-02-13 23:15:34 UTC

I would love to do so but the pics are above 4 Megs in size...(12Mp)  maybe I can try to load them up somewhere...

Comment 6 Mike 2013-02-20 20:28:21 UTC

Hi Gilles,   finally I managed to provide three pics on my webspace who all have problems. 
Here are the links: 
http://scholzmike.net/IMGP1368.JPG
http://scholzmike.net/IMGP1374.JPG
http://scholzmike.net/IMGP1382.JPG

Hope that helps :-)

Best regards,
Michael

Comment 7 caulier.gilles 2013-02-20 22:18:28 UTC

Mike, 

Please look here :

https://bugs.kde.org/show_bug.cgi?id=314822#c6

... and let's me here if the analyse of the problem is reproducible for you...

Gilles Caulier

Comment 8 Mike 2013-02-21 21:59:23 UTC

Update:    like i wrote in 314822:   the solution with adding a "convert to jpg" job solved the problem. A bit strange because the picture already is jpg but it seems a "write" job is needed in any case. Knowing that the BQM works nearly perfect :-)   Thank you Gilles !  

Michael

Comment 9 caulier.gilles 2013-02-22 07:54:29 UTC

Mike, it's abnormal.

Here, i play with JPEG WITHOUT to assign convert to JPEG tool, and it work perfectly.

It sound like a missing test case that i don't see, relevant your settings.

Gilles Caulier

Comment 10 caulier.gilles 2013-03-25 05:55:42 UTC

Mike,

I think the lead problem is fixed now following this report :

https://bugs.kde.org/show_bug.cgi?id=313938

Please checkout current code from git/master (next 3.2.0), and test. 

Thanks in advance

Gilles Caulier

Comment 11 caulier.gilles 2013-07-27 09:19:25 UTC

Git commit dd3dc1cdd2292f2c12b2927250619ae4781f3a61 by Gilles Caulier.
Committed on 27/07/2013 at 09:10.
Pushed by cgilles into branch 'master'.

Batch Queue Manager : add new option to turn on/off multi-core support. This option is now turn off by default due to some dysfunctions under Windows, until it will be hack and fixed.
Note that problem are not reproducible under OSX and Linux here. Options is implemnted for digiKam 3.3.0 release.
Related: bug 318198, bug 318577, bug 320358

M  +13   -1    utilities/queuemanager/manager/actionthread.cpp
M  +1    -1    utilities/queuemanager/manager/actionthread.h
M  +4    -1    utilities/queuemanager/manager/queuesettings.h
M  +9    -1    utilities/queuemanager/manager/workflowmanager.cpp
M  +14   -2    utilities/queuemanager/views/queuesettingsview.cpp

http://commits.kde.org/digikam/dd3dc1cdd2292f2c12b2927250619ae4781f3a61

Comment 12 caulier.gilles 2013-10-31 07:58:39 UTC

digiKam 3.5.0 is out.

Can you give a fresh feedback about your report ? Problem still reproducible ?

Thanks in advance

Gilles Caulier

Comment 13 caulier.gilles 2014-09-01 11:42:13 UTC


*** This bug has been marked as a duplicate of bug 318577 ***

Comment 14 Mike 2014-09-02 16:49:20 UTC

Couldn test it with 3.x since I changed my distro. Now I have 4.2 in use and this problem is solved definitely !  Thanks to all great people involved ! :-)