[KPhotoAlbum] 3.1.0-rc1 released - some problems

[Jan Kundrát]

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)

Well, this annoying behavior is caused by uninitialized settings of
"synchronization precedence" -- in other words, KPA doesn't know what
fields you prefer to get the name from and thus uses an empty list. No
preferences -> no data to import. An easy workaround is to invoke the
settings dialog (which magically has sane default values) and press OK.

This will be fixed before release. It has been documented in the release
notes :) but I see it's retarded.

> 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?

> 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.

> 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"

> 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)
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?

> 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 :(.

> 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.

Thanks for your testing.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20071002/edb5e1f7/attachment.sig>