Bug 89394 - Make CDArchiving tool work when ImageCollection!=Folder
Summary: Make CDArchiving tool work when ImageCollection!=Folder
Status: RESOLVED UNMAINTAINED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-Generic-Archive (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-13 10:33 UTC by Jean-Michel Fayard
Modified: 2018-03-23 21:04 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 0.1.0


Attachments
Preliminary patch (10.85 KB, patch)
2004-09-13 10:40 UTC, Jean-Michel Fayard
Details
Patch against current CVS (18.86 KB, patch)
2004-10-02 00:14 UTC, Jean-Michel Fayard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Michel Fayard 2004-09-13 10:33:27 UTC
Version:            (using KDE KDE 3.2.3)
Installed from:    Compiled From Sources
Compiler:          gcc-3.4 -g 
OS:                Linux

Description : CDArchivingPlugin is broken for an application where ImageCollection!=Folder. The HTML generation doesn't work, and the original pictures which doesn't belong to the same directory as the first picture in the image collection are not burned.

How to reproduce it: 
Go to http://ktown.kde.org/kimdaba/snapshots/ and follow the installation procedure (doing export CFLAGS="-g " before is useful)
Copy the pictures attached right in your home directory and start Kimdaba
File>Archive to CD>Select all keywords, burn an iso in k3b and mount it with :
$ su
$ mount  -o loop -t iso9660 <temporary folder>/CD\ Albums.iso <empty directory>

Patch attached : some preliminary work, basically remplacing each QDir dir = ImageCollection::path() with the equivalent ImageCollection. This also change the directory structure of <cdrom>/<folder>/image.jpg to <cdrom>/<keyword>[1]/image.jpg

[1] : the name of the imagecollection in KimDaBa

Current problems :

* Maybe existing in the original plugin: pictures with latin1 characters doesn't show in HTML generation.
(/mnt/removable/HTMLInterface/inclassables/pages/28 - Mais oui elle est l%3F%3F, ma montre.JPG.html
instead of
/mnt/removable/HTMLInterface/inclassables/pages/28 - Mais oui elle est là, ma montre.JPG.html )

* Maybe existing in the original plugin : slow memory leak. KimDaBa used 95MB after generating a 600MO CD.

* For now, it doesn't try to copy recursively directories. I find it totally broken, because I have one picture in the top directory, it will copy all the top diretory, and then the others subdirectories again for the others keywords.

* Pictures can have many keywords in KimDaBa, so by design, one picture will be copied many times. Does K3B use symlink on a iso when it is possible (with Joliet or Rockridge, I don't know...) ?

* Note that because it now copies the images in a collection and not anymore all files in a folder, it cannot copy other files (comment.xml or whatever) in the directory. If this is a problem, we can use the new ImageCollection::isDirectory() and switch back to the old behaviour.

* Need to try it, and perhaps to make it work again with Digikam


That's all for now ;-)
Comment 1 Jean-Michel Fayard 2004-09-13 10:40:14 UTC
Created attachment 7502 [details]
Preliminary patch
Comment 2 Jean-Michel Fayard 2004-09-13 10:46:59 UTC
http://www.stud.uni-karlsruhe.de/~upaxe/Images.tar.gz
My test case for KimDaBa. This attachment is too big for bugzilla (1.7 MO), so I put it there.

Copy thoses files right in your KimDaBa base directory, so that you override the index.xml file.
Comment 3 Jean-Michel Fayard 2004-09-13 11:47:40 UTC
Oh I forget something, but it should be clear by looking at the test case :

test_image.jpg_1
test_image.jpg_1/image.jpg
test_image.jpg_2
test_image.jpg_2/image.jpg

We need to handle the case when two pictures in two diretories have the same filename and the one common keyword.
Currently, k3b renames thoses pictures in 
<cdrom>/<keyword>/image1.jpg
<cdrom>/<keyword>/image2.jpg

Either we prevent that ourselves, or we correct the HTML files.
Comment 4 Jean-Michel Fayard 2004-10-02 00:14:31 UTC
Created attachment 7753 [details]
Patch against current CVS

Sorry for the last time, I did the change against an old version of the plugin.
Here is the version compiled against current CVS.

I know everybody seems to be moving home ;-), but please take a look, because
good news : the CDArchivingDialog now basically works with KimDaBa.
See the CD made by k3b with my testcase : (1.5 MO)
http://www.stud.uni-karlsruhe.de/~upaxe/temp/a.dir.tar


HTMLInterface/(base folder)/pages/test_latin1_àéèù.jpg.html
like I said before, this doesn´t work, but at least, that´s not my fault ;-)

The rare case where two pictures have the same filename is not handled for now,
but it´s so rare that we can give up for now.
Comment 5 Jean-Michel Fayard 2004-10-02 00:32:01 UTC
And now the CD generated by k3b when your virtual albums are not folders (like by default) but Keyword (breaking the assumption album == directory)
You can change this so :
Menu Settings > Configure KimDaBa > General > Category vor virtual albums (choose Keywords)

The CD generated by k3b is here :
http://www.stud.uni-karlsruhe.de/~upaxe/temp/b.dir.tar


Additional note : As discovered by Jesper, newer versions of k3b require the "--nofork" to work, while older versions of k3b will return with an error if you pass this option. You need to auto-detect this, I hardcoded it for me.
Comment 6 David Fraser 2004-10-19 12:54:42 UTC
See also bug 91651
This is that if the first image is in the top directory, all the files in that directory get put on the CD
Description:
I selected a set of images in kimdaba
I then ran the CD Archiving plugin.
It said that there was about 470MB of images. I clicked to continue
It took a long time to generate the thumbnails ...
When it got into k3b, it said there was 4 GB of images ... it had included all of the images (the whole directory)
It should have only had those items I had selected.
All of my images are in the same folder. 
Comment 7 David Fraser 2004-10-19 14:40:41 UTC
I tried the "Patch against current CVS" but it seems to break things - when I run the plugin K3b never appears, it just goes to "removing thumbnail images from temporary folder..."
Comment 8 Jean-Michel Fayard 2004-10-21 10:17:32 UTC
comment 7
An important other bug is that old versions of k3b requires no cmdline arguments while newer versions requires --nofork
and the plugin relie on this to work.
As I said somewhere, I hardcoded this for my version (--nofork), please try without that
Comment 9 Renchi Raju 2005-02-07 02:57:32 UTC
*** Bug 98496 has been marked as a duplicate of this bug. ***
Comment 10 Tom Albers 2005-08-19 20:12:08 UTC
SVN commit 450825 by cgilles:

CDArchiving kipi plugin : patch from Owen Hirst
CCBUGS: 98269 89394 91651 100877 106568



 M  +490 -612  cdarchiving.cpp  
 M  +16 -48    cdarchiving.h  
 M  +6 -2      plugin_cdarchiving.cpp