[KPhotoAlbum] Import crash

[Robert Krawitz]

On Thu, 18 May 2017 00:10:39 -0400, Joe wrote:
> On 05/17/2017 09:59 PM, Robert Krawitz wrote:
>> On Wed, 17 May 2017 21:07:25 +0200, Johannes Zarl-Zierl wrote:
>>> On Dienstag, 16. Mai 2017 21:54:01 CEST Robert Krawitz wrote:
>>>> On Mon, 15 May 2017 22:46:55 +0200, Johannes Zarl-Zierl wrote:
>>>>> So I guess many of the imported images are already in the database? This
>>>>> would lead to a direct recursion. As a quick fix I guess we could bypass
>>>>> the direct call to aCopyJobCompleted(0) in copyNextFromExternal() in the
>>>>> default case...
>>>> I did it by having aCopyJobCompleted() set (clear) a flag to indicate
>>>> whether to continue looping.  But there's a new problem: as the import
>>>> progresses, I get messages like this:
>>>>
>>>> kf5.kio.core: Invalid URL: QUrl("img_6004_c2.jpg")
>>>> kf5.kio.core: Invalid URL: QUrl("img_6005-5.jpg")
>>>> kf5.kio.core: Invalid URL: QUrl("img_6006-5.jpg")
>>>> kf5.kio.core: Invalid URL: QUrl("img_6007-6.jpg")
>>>> kf5.kio.core: Invalid URL: QUrl("img_6008-5.jpg")
>>>> kf5.kio.core: Invalid URL: QUrl("img_6009-6.jpg")
>>>>
>>>> That's because the export file creates unique filenames even if the
>>>> files live in different directories (I presume because if you actually
>>>> exported the images, rather than the file, they'd live in one
>>>> directory so would need unique filenames):
>>> [snip]
>>>
>>>> So this probably isn't going to do what I want after all.  Rats.
>>> Just to be clear about the problem: You end up with a bunch of non-existing images in the database, in addition to the original that is already in the database?
>> I didn't let it run that far.  It was prompting me for the location of
>> each file, and I punted at that point.
>>
>>> If so, maybe you can help things along by using the "Find duplicates" dialog.
>>>
>>> A proper fix needs to change the way we create export files. In the
>>> past, I was always hesitant to touch the .kim file format in order
>>> to avoid compatibility problems. Maybe it's time to revisit this
>>> decision...
>> I agree it needs to be backward compatible, so a newer kpa can import
>> an older .kim file.  I don't think the other direction is necessary;
>> if an old kpa can't import a new import file, you upgrade.
> While I totally agree with this in principle, sometimes you can't
> upgrade because of dependencies.  I had an install of something from
> a tarball fail today because of that.
>
> The question then becomes: Are there any plausible scenarios where
> you would have a newer version the .kim file (which had to be
> generated on a newer version of KPA to start with) and still need to
> use it with an older version of KPA. I don't know the answer. E.g.,
> Do all users have QT5 installed?

By now, I'd expect that most users of modern distributions have QT5
installed.  But there's nothing unusual about requiring upgrades to
take advantage of full functionality, including file formats.

>> For that matter, a lot of times when I'm doing an import I'm really
>> not interested in selecting which files I want to import; just grab
>> the whole thing and go.
> I'm  not sure if the following is relevant or not. I'm used to thinking about files and directories, not the content of databases.
>
> I would suspect that this is the most common case. I always have my photos batched into directories and operate on whole directories. In any case, that's what file managers and shell scripts are for.
>
> KPA should be able to do such things (especially if it already does), but it probably doesn't need to be very efficient at it because it may not be used that frequently.

In this case, it's the database content I want to migrate, as I
already have file migration taken care of, but there are some files in
one that aren't in the other so I can't simply copy the index.xml.
I'm sure I could come up with some script to migrate the data, but it
likely would be messy and prone to all manner of corner cases.
-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton