[Digikam-users] Syncing Digikam collections and databases between different computers
Gilles Caulier
caulier.gilles at gmail.com
Wed Dec 3 09:51:45 GMT 2014
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
More information about the Digikam-users
mailing list