Bug 315025 - 0Byte sized files after using 2 actions in Batch Queue Manager
Summary: 0Byte sized files after using 2 actions in Batch Queue Manager
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-Bqm-Convert (show other bugs)
Version: 3.0.0
Platform: Ubuntu Linux
: NOR major
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-12 22:31 UTC by Mike
Modified: 2016-07-04 08:29 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.3.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 ! :-)