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

Jürgen Blumenschein blumenschein at dokom.net
Thu Dec 4 09:31:24 GMT 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jonathan,

that's exactly my problem!
How can I avoid this extra and unnessaccary scanning of all folders?
Is there any switch or other way to get an fast starting digikam?

Jürgen Blumenschein

Am 03.12.2014 um 21:37 schrieb Jonathan Ballet:
> 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
> _______________________________________________ Digikam-users
> mailing list Digikam-users at kde.org 
> https://mail.kde.org/mailman/listinfo/digikam-users
> 


- -- 
Jürgen Blumenschein, eMail: blumenschein at dokom.net
Homepage: http://huntington-info.eu/
Am Quartus 17
D-44149 Dortmund
Tel.: +49 231 7217321, Fax: +49 231 47690509
public key:
http://members.dokom.net/blumenschein/Juergen_Blumenschein_(0xC9358EBB)_public_key.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iEYEARECAAYFAlSAKewACgkQ7vXR4Mk1jruLOwCgoogWgvk2oatiucwvEtcYj2kM
4Y4AoMBnlI/0BIfyZEoV4bI1Bjo1T1Be
=E0jA
-----END PGP SIGNATURE-----



More information about the Digikam-users mailing list