[KPhotoAlbum] 3.1.0-rc1 released - some problems

Martin Jost lists at majo.name
Thu Oct 4 16:31:48 CEST 2007

Jan Kundrát schrieb:
> Martin Jost wrote:
>> When first detecting new images using RC1, the images were found, but
>> the file name so far visible below the image was missing.
>> (For the "old" images it was still present)
> [...]
> This will be fixed before release. It has been documented in the release
> notes :) but I see it's retarded.
We agree on this ;-)
(And I will try to get hold of the release note - and really read it.)
>> I tried to recreate this using "Re-Read Meta Data from file".
>> This resulted in a crash. See attached file KPA_reread_crash.
> Hmmm, that's an unhandled exception when trying to create an Exif field
> key for lookup in already-read metadata. I guess this is because of a
> key name that your exiv2 library doesn't support. Please try r720262, it
> will print a debug message to stderr when that occurs. What exiv2
> version is that, btw?
I will try to get this version (At the moment I only have a 56 K modem
and have to unplug the phone and roll out 7 meters of cable to get to
the internet, This slows down things like this somewhat)
I will report the outcome of this.
My current version is exiv2-0.12
>> At the first try of this, KPA then crashed right at startup (after
>> reading the DB), see KPA_restart_crash.
>> (I didn't see this right now at a second try.)
> Same as above. It should be possible to trigger this bug by attempting
> to re-read metadata from files that weren't touched by the IPTC export.
Ok. After doing your workaround (" An easy workaround is to invoke the
settings dialog (which magically has sane default values) and press
OK.") I now get the crashes on reading the new images at start-up ;-)
See attached backtrace. (Just to be sure, it is the same problem)
>> I then had KPA from SVN read the new images
> "from SVN"? Current SVN is in fact post-RC1, so I'm a bit confused here,
> I guess you mean "SVN before that big IPTC merge"
Yes I mean this; I could have been more precise :-(
This version is rather old. It contains the "reuse last tag"-button in
the tagging window. (The feature I had asked for and urgently wanted.)
It is *not* from the IPTC branch and clearly before the merge.
>> But just now- one day later -  I had to find that somehow KPA RC1
>> managed to write an empty index.xml without a current .#index.xml.
>> So my tagging action is gone (The first hard data loss by KPA).
>> Fortunately I have a backup from before the tagging.
> Umm, I don't see any way that recent changes might have introduced that.
>  If the file is really empty (as in "zero bytes"), it could be (AFAIK)
Yes "really empty" (As in "zero, null, nil, void, it's pushing the
daisies from below - uhm that was another story - SCNR)
Not even a XML-header - just plain emptyness.

> caused only by:
> a) memory corruption
> b) Qt's DOM library screwup
> c) system crash
> d) filesystem acting funny
> How did it happen? What filesystem is that?
Sorry, I don't know how it happened, because I discovered it one day
later. (So no, nothing unusual before)
The filesystem is ReiserFS 3. I'm not aware of any hardware problems on
the machine. Definitely no system crash.
One possible cause, could probably be a screwup of hibernate/suspend.
(I'm not saying that KPA is the culprit, but updating to RC1 and short
after this the first data loss from KPA, makes this an easy first guess)
I will try to keep the history better in mind and report if I find
similar things again.
>> Another problem seems to be in the IPTC export.
>> I tried to use this to have JALbum read the IPTC tags to give meaningful
>> descriptions to my photos.
>> For some photos this worked, but other photos now had JAlbum barf with
>> an internal error. (The same bunch of pictures where accepted by JAlbum
>> before the IPTC export in KPA without problems).
> "JALbum bug", I guess. It's hard to say more without seeing a
> more-detailed error message :(.
The JAlbum message looked very much like "Ops, something really
unexpected happened"
At least I would expect that JAlbum is able to just skip unknown IPTC
OTOH if KPA produced some complete nonsense from JAlbums point of view...
>> I will try to reproduce this with downscaled photos, so I can post
>> examples. (Don't know when I will find the time for this)
> If you are worried about posting huge files to the ML, I have no problem
> with hosting them somewhere on the web.
Ok, let's see what I can do.
> Thanks for your testing.
Your welcome ! Thanks for making an already great program better.
I'm pleased if I can help with this, at least a little bit.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: KPA_readnew_crash
Url: /mailman/pipermail/kphotoalbum/attachments/20071004/7247aac5/attachment.ksh 

More information about the KPhotoAlbum mailing list