<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi everyone,</p>
    <p>IMHO, the export/import feature via *.kim files could need some
      love. I use this feature quite extensively and stumbled across
      several smaller and larger problems. Some of that might be bugs,
      some might be usability issues and some might just be
      p.e.b.k.a.c...</p>
    <p>My main reason to use more than one database is backup. I do not
      need every single image on off-site backup - only "valuable"
      images. Thus a curated subset gets moved (via kim) to a separate
      database / folder tree that is then backed up regularly.</p>
    <p>kim feature:</p>
    <p>1) There seems to be a size limit of ~4GB for *.kim files: I can
      easily export larger *.kim files but on import KPA says "cannot
      open the file for reading" (or so). Exporting the images with
      "copy next to kim file" works, but that clutters my folder with
      1000s of files.<br>
      ark also complains about the files (after renaming them to *.zip).
      Thus, the size limit is most probably a feature of the zip
      library.<br>
      => It would be nice if the size limit should be flagged before
      exporting. Or the export stops when the limit comes close while
      giving the option to split the export into multiple files.</p>
    <p>2) After importing the images the files do not retain their
      original time stamp (on the file system). This is OK for images
      but bad for videos, as date/time gets updated from "exif" data -
      but in case of videos from the file system time stamp. There is a
      corresponding bug report: <a class="moz-txt-link-freetext"
      href="https://bugs.kde.org/show_bug.cgi?id=511440"
      style="white-space: pre-wrap;">https://bugs.kde.org/show_bug.cgi?id=511440</a></p>
    <p>I have a workaround, but this is quite clumsy: a script that
      reads the (possibly corrected) timestamps from index.xml and
      updates the exif data (also in videos), then a script to touch the
      files after import with the timestamp from exif and finally "read
      exif data from file" in KPA. sigh!</p>
    <p>2a) The timestamp formats in index.xml and *.kim are different. I
      there a technical reason or is that just baggage from the past?</p>
    <p>3) The default folder for reading the import file from: When I
      import several *.kim files in one session, the file open dialog
      for the *.kim file shows the last destination folder for the
      images, not the folder the *.kim files reside in. It would be nice
      if KPA could remember where the kim file came from and propose to
      read the next kim file from there.</p>
    <p>4) The import dialog: the destination folder should be asked
      first, because that is the one dialog, where you need to input
      something most often.</p>
    <p>5) The category matching on import: it would be nice to filter
      for category items that do not match 1:1 existing items - to be
      able to correct them. These are often overlooked because KPA
      automagically selects "similar" existing items. This can cause
      quite a bit of trouble.</p>
    <p>6) I would really like a method to synchronize
      categories/category items between databases</p>
    <p>one more thing:</p>
    <p>7) When deleting files from disk (from the KPA dialog), the files
      get added to the blocklist. But they shouldn't. Deleted from disk
      and deleted from the database should be enough. I do not know how
      often I had to clear the blocklist manually with the editor
      (thanks for a human readable database!). This is a problem if I
      need to import the same images again (e.g. after some corrections
      in the original database).</p>
    <p>I understand, that the blocklist is necessary to delete files
      from the database only.</p>
    <p>Is any of this worth to add a feature request / bug on
      bugs.kde.org?</p>
    <p>Cheers, Andreas</p>
  </body>
</html>