[KPhotoAlbum] KPA 3.1.0 RC1 not importing data / crash on cancel

[Martin Jost]

Jan Kundrát schrieb:
> Martin Jost wrote:
>> Yes - I tried twice with the same outcome (But I didn't compare the
>>  stack trace)
>
> Please try again with r722715 (or newer). It seems that this was
> triggered by a missing file (we were waiting for a signal that never
>  arrives and canceling would yield a null-pointer dereference).
> Thanks for reporting.
>
Hello Jan,

sorry, I got the next crash. You may call this an unfair trick on KPA.
This time I got to the actual import (So the situation improved)
What I wanted, was to only import the meta data (the one present in
index.xml), while the photos were already there. (Hand copied from a DVD)

Because I was somewhat afraid, that KPA could somehow manipulate the
already present photos, I gave a "wrong" import directory to KPA, which
contained no photos.
Now the import complained on every photo, that the actual photo couldn't
be found.
After some big amount of "ok-clicking" (once for each photo) KPA finally
crashed with the attached trace.
On the konsole I got:
ASSERT: "it.node != node" in /usr/lib/qt3/include/qvaluelist.h (301)
KCrash: Application 'kphotoalbum' crashing...

So I copied the thumbnails from the .kim file to the the dir, where KPA
expected the photos.
This time the progress bar went up to 99 % rather quick, then stopped.
I had to kill KPA

Martin

P.S.:
I still would like a feature to tell KPA "just import the meta data".
(KPA would be perfectly free, to mark meta data with missing jpeg files
as "not present" later on. (gray "photos" with  snipped off edge))

And while I'm at it:
There is another somewhat frightening looking feature of the import:
Look at the attached screenshot. (The problem is the same for each
category like "Persons", "Places", etc.

This lists all found values for a key found in the file.
Not only does this look completely unmanageable, the question is: What
would KPA do, if I
map the first "Elias" to "Elias A." and the second one to "Elias Z." ?
(Probably right now, it will do the first mapping for the first photo
and the second for the second photo ...)
IHMO the only sensible thing is, to have one mapping for each *unique
key* found in the file.
This would also bring down the count of keys to manageable amount.
(Do I miss something ?)

Ok, I admit this probably getting difficult for the new release. Let me
know, if I should generate Bugzilla entries for some of the points.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: KPA_import_crash2
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20071008/1daa16fb/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: importDlg.png
Type: image/png
Size: 33367 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20071008/1daa16fb/attachment.png>