Migration problems - Digikam 1.8 to 2.0

[Gilles Caulier-4]

2011/9/13 KrpaN <[hidden email]>:

> On 13. 09. 2011 11:27, Rinus Bakker wrote:
>>>
>>> Bojan
>>>
>> Well, that is indeed a complete different question. I did many such
>> migrations without any problem i.e. from one computer to another, not from
>> user to user, but that should be not harder.
>>
>> I am taking here about linux, so I hope you are on linux too
>>
>> #############################################
>>
>> Yes, I am on Linux. And just copying directories with photos and
>> digikam4.db never helped. There must be something else or in a different
>> way. Writing metadata, as suggested by one guy, made no difference at all.
>> So, any useful suggestion, that would help to keep My Tags intact, is
>> appreciated.
>>
>> Bojan
>
> You should read my message more carefully, I was not talking about just
> copieing stuff, I explained a detailed verified procedure to you.
> If you encounter trouble to follow the procedure, you are invited to ask for
> specific help at each point.
>
> I guess, you hoped for a magic answer, there isn´t, you have just to follow
> the procedure.
>
> Best regards,
> Rinus
>
> Now, after doing some googleing I came across the following question. Is
> digikam in any weird way associated with akonadi. Because I have disabled
> akonadi, but whenever I run digikam the akonadi is up and running again.
>

No. digiKam do not use Akonadi, and will never use it...

Gilles Caulier
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[davidvj]

CONTENTS DELETED

The author has deleted this message.

[Photonoxx]

Le Tue, 13 Sep 2011 10:49:15 +0200, Rinus Bakker  
<[hidden email]> a écrit:

>
> I am taking here about linux, so I hope you are on linux too
>
> #############################################
>
> locate your db´s:
> digikam4.db
> thumbnails-digikam.db
>
> and move them where you want them
>
> in your new computer open with gedit ~/.kde/shar/config/digikam.rc
>
>
> you will find two lines referring to your digikam database. Take care  
> this
> point to the place where you moved them.
>
> do the same with your photos, store them on your new computer BUT VERY
> IMPORTANT take care the path looks EXCACTLY the same as on your old  
> computer
>
> example /home/Bojan/media/photo/ this means that the name of your drive
> where your fotos are stored should be the same as in the former  
> situation,
> else you would confuse your database.
>
> start digikam on your new computer.
>
> goto settings->configure digikam->database
>
> and point to the place where you stored it on the new computer and click  
> ok
>
> Now it may complain about albums not found, because of a differen  
> harddisk
> id or somthing.
> remove the albums, if they are there from settings->configure
> digikam->collections and re add them. Take care to add exacly the same
> albums as in the former situation.
>
> Now it start rereading everything, and you will probably end up with the
> same as you started with. Anyway it always works for me and it is easy to
> do.
>
> DONE!

IMHO, I prefer to use an external USB Disk with on it my photos and my DB.

The worse which can happen is I launch Digikam without plugging the disk  
and have to quit and re-launch after plugging it.

If the disk doesn't have mount point in /etc/fstab it will be mounted when  
plugged with the name of partition label (so potentially the same on all  
linux system).

After that, you just have to set Digikam to look for DB and pictures on  
this disk.

Obviously, you need to have the permission to read write on this partition  
(so fat32 or NTFS with adequate default mounting options).


I just close this message by adding my voice to Martin Burnicki and  
Jean-François Rabasse words about Raw metadata writing. As sidecar seems  
not yet standardized (even for software which use them) and could be lost  
too (if batch renaming pictures but not sidecar), I thing embedding  
metadatas in RAW files is not a bad way to tag pictures.

Most of manufacturer software use this method I think (and at least  
CaptureNX for NEF files), so if it's a so risked way to proceed, I don't  
think manufacturers will use it.

The second key is making backup. I think having two backup is good. One  
made when you import your pictures from camera or memory card  
(Rapid-Photo-Downloader make this perfectly) and an other made regularly  
 from your working directory to have a backup of the modification you made  
to your files.

In the worse case, you still can get back your files "backuped" from "out  
of the camera".

I sometimes had some trouble with metadata Raw writing, but most of the  
time I don't have to use backup, setting one more time the tags with  
patched exiv2 get back functional RAW files.

--
Nicolas Boulesteix
Photographe chasseur de lueurs
http://www.photonoxx.fr
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jean-François Rabasse]

Hello,

A comment about backups :

On Tue, 13 Sep 2011, Photonoxx wrote:

> The second key is making backup. I think having two backup is
> good. One made when you import your pictures from camera or memory
> card (Rapid-Photo-Downloader make this perfectly) and an other
> made regularly from your working directory to have a backup of the
> modification you made to your files.
>
> In the worse case, you still can get back your files "backuped"
> from "out of the camera".

I fully agree with the concept of two different backups, because an
image (from a photographer's point of view) is not one file but,
at least, two; and a formulation written by David,

On Tue, 13 Sep 2011, David Vincent-Jones wrote:

> We Linux photographers, are now in the enviable position of having
> a plethora of fine products to turn our raw material into finished
> images etc.

is excellent. True, we have the "raw material" file, and the
"finished image" file. So, having a backup (or one should rather say
an archive) of raw files, just in case, plus periodic backups of
finished images (may be tagged, as the raw file is preserved:-)
seems to be a safe way.

As for databases themselves, good backups should prefer databases
dumps, rather than the binary .db file(s).

For those not very familiar with SQL databases, a DB dump is a
(huge) text file, containing all the SQL commands needed to recreate
then repopulate a database from scratch. And it's a very important
interchange tool when changins software versions. In some cases,
a binary .db file may raise problems with a newer version of the DB
software. Doing a dump with the older version, then recreating with
the newer version could allow transitions without problems.

With SQLite, doing a dump will be one command :
     sqlite3 digikam4.db .dump > dk-dump.sql

(mind the dot before the keyword .dump)
and you get a text file containing all SQL commands to rebuild.

When you want to rebuild from scratch, you don't even need to have
already a database file, it will be created on the fly with the
command :
     sqlite3 test.db < dk-dump.sql

Can check it,
     sqlite3 -line test.db 'pragma integrity_check;'

then you can rename test.db to digikam4.db

(Also, the SQL dump format allows possible migration of your data to
another DB software, e.g. MySQL or PostgreSQL.)

I think that this text format is more flexible than the binary
format and doing backups with dumped versions of databases is safe
for a longer term.
(Those files are large, but it's only text and can be gzip'ed)

Jean-François

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users