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

[Mick Sulley]

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