[Digikam-users] Syncing Digikam collections and databases between different computers

Jonathan Ballet jon at multani.info
Wed Dec 3 20:37:29 GMT 2014 

Just to be clear: when I synchronize my photos and databases between my
computers, I get the same dialog as you mentionned, and I don't lose any
pictures or other information in the process.


Still. One of the computer is a netbook and is, to be honnest, kind of
slow. Each time I get this dialog and I confirm the UUID change, it
seems it's rescanning all the folder of my collections, and scanning
30GB+ on this computer takes more than 15 minutes in this case.

Now, if I was doing this once in a while, I wouldn't really complain,
but I'd like to also have these pictures on my desktop computer, which
is a bit faster (just a bit, because it still takes ages to work on
these pictures), so I regularly synchronize both computers. It works
fine all the time, but I have to wait for Digikam to fully start
before being able to work comfortably (and you now, IO activity...),
although I have the *exact same Digikam settings (files, databases,
photos)* on both computers.

So, there's no dysfunction in itself. Digikam only seems to do extra
work because it detects the UUID changed, although there is, in my
opinion, no need to do anything (in my case case. I understand there can
be other use cases I didn't consider).

 Jonathan (still pondering the problem)


On Wed, Dec 03, 2014 at 10:51:45AM +0100, Gilles Caulier wrote:
> I remember an experience few month ago, where i moved my whole
> collection from a 25Gb SDD to a new 512Gb SDD on my host linux
> computer.
> 
> I simply move all dirs and restarted digiKam. Immediately, it detect
> the changes about HDD unit (it do not found older SSD and detect new
> one) and a dialog ask to see if new device with new UUID is the right
> one.
> 
> Note that both units (older and newer) have been mounted on the same path.
> 
> Typically, if this detection work fine everywhere, there is no need to
> have an advanced edit mode from Collection config dialog.
> 
> Note that hardware device is delegate to KDE::Solid API. Perhaps the
> dysfunction appear in this component.
> 
> Gilles Caulier
> 
> 2014-12-03 10:37 GMT+01:00 Jonathan Ballet <jon at multani.info>:
> > Hi Andrew,
> >
> > On Mon, Dec 01, 2014 at 10:57:35PM +0000, Andrew Goodbody wrote:
> >> Please look at the bug here https://bugs.kde.org/show_bug.cgi?id=261277 It
> >> contains information about updating the albumroot entry and you can even
> >> have multiple values for accessing the same files from different systems, in
> >> comment #13. Unfortunately there is still no GUI frontend to edit this in a
> >> user friendly manner.
> >
> > when I first read the report, I didn't see the relation with my problem,
> > but then I stumbled upon comment #20 (which should have been the one
> > you wanted to talk about, I suppose?) and replaced the entry in the
> > database from:
> >
> > sqlite> SELECT id, identifier, specificPath FROM AlbumRoots;
> > id    identifier                                           specificPath
> > ----  ---------------------------------------------------  ------------------
> > 1     volumeid:?uuid=bd411a98-5c98-4370-89ee-551f180b09c1  /jon/images/photos
> >
> > ... to the following:
> >
> > sqlite> SELECT id, identifier, specificPath FROM AlbumRoots;
> > id    identifier                              specificPath
> > ----  --------------------------------------  ------------
> > 1     volumeid:?path=/home/jon/images/photos  /
> >
> > which seems to work as I wanted this to work in the first place.
> >
> > I don't know what's the logic behind the 'identifier' field, I have I
> > think a much simpler use-case than what it seems to be intended for, but
> > at least storing the path of the collection makes more sense to me.
> >
> >> Still however I think a better solution would be to have the albumroot
> >> information stored in the digikamrc file and only have the relative paths in
> >> the database.
> >
> > I like the idea of having the collections and all their data
> > self-contained. But I completely understand that might be a problem when
> > moving folders around between different machines with different folder
> > structures...
> > Indeed having the album root configuration stored in a different place
> > would have also probably helped me in this case...
> >
> >  Jonathan
> >
> >
> >> Andrew
> >>
> >> On 01/12/14 20:25, Mick Sulley wrote:
> >> >Yes agreed!  I think it should be possible to arrange a SQLite script to
> >> >auto run to change the UUID back to what it expects, but I have not
> >> >tried it.  I cannot really see why the UUID is in that record at all,
> >> >the path is there and that should be sufficient I would have thought.
> >> >
> >> >If you do come up with a way to automatically sort it out please share.
> >> >
> >> >Mick
> >> >
> >> >
> >> >On 01/12/14 20:07, Jonathan Ballet wrote:
> >> >>Hi Mick,
> >> >>
> >> >>thanks for your reply!
> >> >>
> >> >>On Sun, Nov 30, 2014 at 06:54:10PM +0000, Mick Sulley wrote:
> >> >>>Hi Jonathan,
> >> >>>
> >> >>>Yes I raised this when I started using DigiKam, as far as I know
> >> >>>there is no
> >> >>>proper fix.  If you just accept at the message it works OK, just takes a
> >> >>>little time.  It is also possible to add a database script to fix it,
> >> >>>here
> >> >>>is an answer that I received to that question back in 2013.  I never got
> >> >>>around to creating the script, I just accept when asked.
> >> >>I would be OK just to accept this, but my laptop is not *that* powerful
> >> >>and it takes ages just to rescan all the images, even if nothing
> >> >>changes.
> >> >>
> >> >>I'm going to try such a script, as you mentioned, although it's going
> >> >>to be, at best, impracticable.
> >> >>
> >> >>I actually wonder what is the purpose of this UUID. If I choose to store
> >> >>the content of Digikam's database into MySQL, is this also stored? I
> >> >>supposed that using a remote database server was to allow sharing
> >> >>between several computers, but if it's stored, that more or less defeats
> >> >>the purpose of having a remote database, isn't it? And if this UUID is
> >> >>not stored, then I wonder what it is using SQLite?
> >> >>
> >> >>Hum, I guess I'll need to have a look...
> >> >>
> >> >>  Jonathan
> >> >>
> >> >>
> >> >>>On Wed, 20 Feb 2013, Mick Sulley wrote:
> >> >>>
> >> >>>>Hi,
> >> >>>>
> >> >>>>When I sync my album between laptop and desktop I get a message when I
> >> >>>>open it on the destination machine saying that the collection is
> >> >>>>available
> >> >>>>but the identifier has changed.
> >> >>>>
> >> >>>>I have looked in the database on each machine and it seems that the
> >> >>>>problem is that the AlbumRoots table is slightly different, the
> >> >>>>identifier
> >> >>>>field is different -
> >> >>>>desktop = "volumeid:?uuid=bf835257-ad63-4580-9692-9d2600740cd1"
> >> >>>>laptop = "volumeid:?uuid=2a6a238c-c404-46b6-886f-873683917b9c"
> >> >>>>
> >> >>>>It does seem to be OK if I just accept the message and continue, but is
> >> >>>>there any way to stop it happening?  Is it likely to cause any
> >> >>>>problems?
> >> >>>Hi Mick,
> >> >>>
> >> >>>Well, this is an old issue, often discussed on this list.
> >> >>>Identifying disk devices by UUID, instead of mount pathname as it should
> >> >>>be - at least on Unix platforms - makes the database hardware dependant.
> >> >>>
> >> >>>Same problem occurs if you manage your collections on USB drives,
> >> >>>even on
> >> >>>the same machine. Changing a drive by a backup drive, or replacing an
> >> >>>old
> >> >>>drive by a new one with a mirror copy of collections will also change
> >> >>>the
> >> >>>physical device UUID.
> >> >>>
> >> >>>The (dirty) fix to work around sync problems is to use small scripts to
> >> >>>make the transfert, e.g. using rsync, then update the database from
> >> >>>SQL command line tool and issue things like that :
> >> >>>UPDATE albumroots SET identifier = 'volumeid:?uuid= new UUID'
> >> >>>  WHERE identifier = 'volumeid:?uuid = old UUID';
> >> >>>
> >> >>>Jean-François
> >> >>>
> >> >>>_______________________________________________
> >> >>>Digikam-users mailing list
> >> >>>Digikam-users at kde.org
> >> >>>https://mail.kde.org/mailman/listinfo/digikam-users
> >> >>_______________________________________________
> >> >>Digikam-users mailing list
> >> >>Digikam-users at kde.org
> >> >>https://mail.kde.org/mailman/listinfo/digikam-users
> >> >
> >> >_______________________________________________
> >> >Digikam-users mailing list
> >> >Digikam-users at kde.org
> >> >https://mail.kde.org/mailman/listinfo/digikam-users
> >> >
> >> _______________________________________________
> >> Digikam-users mailing list
> >> Digikam-users at kde.org
> >> https://mail.kde.org/mailman/listinfo/digikam-users
> > _______________________________________________
> > Digikam-users mailing list
> > Digikam-users at kde.org
> > https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users

More information about the Digikam-users mailing list