Syncing Digikam collections and databases between different computers

[Jonathan Ballet]

Hi,

I would like to keep in sync my pictures and my Digikam settings between
2 computers, my laptop and my workstation. I currently have a setup
where I have one collection in one folder, with the Digikam databases
inside (digikam4.db and thumbnails-digikam.db), and everything is kept
in sync with Unison [1].

It nearly fits completely what I try to achieve, but syncing the
databases has some problem : it seems there's a UID which is connected
to the collections defined in digikam4.db and this UID is different on
both computers, although Digikam settings (as far as I know) are the
same on both: this is collection is the exact same folder, at the same
position in the file system hierarchy, same permission, same kind of
"local" folder, etc.
The problem arises when I'm syncing the database from A to B, and then
open Digikam on B, where it says that it couldn't find the collection
"bla" because the UID is different, but it seems it moved to the
following folder, etc., and then it spends quite some time trying to
figure out if there are new pictures in this collection...

Is there a way to minimize this problem? Is there a way to make these
UID the same on both computers? Or what should I try to keep them in
sync?

Thanks!

 Jonathan

ps: my laptop is not always connected to a network, hence I can't really
use a database server to store Digikam's database, nor can I move the
photos files on a remote filesystem, as far as I am aware.

[1] http://www.cis.upenn.edu/~bcpierce/unison/
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Mick Sulley]

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.

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
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jonathan Ballet]

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
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

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

[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
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

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

[Jonathan Ballet]

I would be happy to try to propose a patch to remove this from Digikam,
but I would have liked to know first why there was such an UUID stored
(I guess there's a good reason?) and if there was a chance for a patch
to be accepted...

 Jonathan


On Mon, Dec 01, 2014 at 08:25:39PM +0000, 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

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

[Gilles Caulier-4]

UUID is used to identify a disk, especially with removable media.

Gilles Caulier

2014-12-01 21:39 GMT+01:00 Jonathan Ballet <[hidden email]>:

> I would be happy to try to propose a patch to remove this from Digikam,
> but I would have liked to know first why there was such an UUID stored
> (I guess there's a good reason?) and if there was a chance for a patch
> to be accepted...
>
>  Jonathan
>
>
> On Mon, Dec 01, 2014 at 08:25:39PM +0000, 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
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

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

[Andrew Goodbody]

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.

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.

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
>>> [hidden email]
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

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

[Jürgen Blumenschein]

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


I have the same problem using the collection on different computers
(e.g. with rsyncing or with nfs-mounts).
Is there a possibility to bring this problem under each users own
responsibility:
An option field in the album/collection dialog to use or not use
uuids. Or if thats not possible to give on (own risk) a fake uuid
via option (e.g. uuid=ffffffff-ffff-ffff-ffff-ffffffffffff).

Jürgen Blumenschein

Am 01.12.2014 um 23:03 schrieb Gilles Caulier:

> UUID is used to identify a disk, especially with removable
> media.
>
> Gilles Caulier
>
> 2014-12-01 21:39 GMT+01:00 Jonathan Ballet <[hidden email]>:
>> I would be happy to try to propose a patch to remove this from
>> Digikam, but I would have liked to know first why there was
>> such an UUID stored (I guess there's a good reason?) and if
>> there was a chance for a patch to be accepted...
>>
>> Jonathan
>>
>>
>> On Mon, Dec 01, 2014 at 08:25:39PM +0000, 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
>> _______________________________________________ Digikam-users
>> mailing list [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________ Digikam-users
> mailing list [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

- --
Jürgen Blumenschein, eMail: [hidden email]
Homepage: http://huntington-info.eu/
c/o Sozialdienst St. Josef Hospital
Gudrunstraße 56, 44791 Bochum
Tel.: [phone], Fax: [phone]
public key:
http://members.dokom.net/blumenschein/Juergen_Blumenschein_(0xC9358EBB)_public_key.asc

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

iEYEARECAAYFAlR9wWIACgkQ7vXR4Mk1jruQkwCg7TDQs6VGlhDrjtg3LfmFXCnU
F10AnjbV8iB3ldmg53Xiy8Yet/RFgFhh
=xG+e
-----END PGP SIGNATURE-----
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Huntington-Beratung]

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


I have the same problem using the collection on different computers
(e.g. with rsyncing or with nfs-mounts).
Is there a possibility to bring this problem under each users own
responsibility:
An option field in the album/collection dialog to use or not use
uuids. Or if thats not possible to give on (own risk) a fake uuid
via option (e.g. uuid=ffffffff-ffff-ffff-ffff-ffffffffffff).

Jürgen Blumenschein

Am 01.12.2014 um 23:03 schrieb Gilles Caulier:

> UUID is used to identify a disk, especially with removable
> media.
>
> Gilles Caulier
>
> 2014-12-01 21:39 GMT+01:00 Jonathan Ballet <[hidden email]>:
>> I would be happy to try to propose a patch to remove this from
>> Digikam, but I would have liked to know first why there was
>> such an UUID stored (I guess there's a good reason?) and if
>> there was a chance for a patch to be accepted...
>>
>> Jonathan
>>
>>
>> On Mon, Dec 01, 2014 at 08:25:39PM +0000, 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
>> _______________________________________________ Digikam-users
>> mailing list [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________ Digikam-users
> mailing list [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

- --
Jürgen Blumenschein, eMail: [hidden email]
Homepage: http://huntington-info.eu/
c/o Sozialdienst St. Josef Hospital
Gudrunstraße 56, 44791 Bochum
Tel.: [phone], Fax: [phone]
public key:
http://members.dokom.net/blumenschein/Juergen_Blumenschein_(0xC9358EBB)_public_key.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iEYEARECAAYFAlR9wJoACgkQ7vXR4Mk1jruH0QCgpR+h4cF8C1hnOYmciYAbKQdg
80oAn2S3VAuKx320XBKdUdp00sfAydsT
=ont3
-----END PGP SIGNATURE-----
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jonathan Ballet]

Hi Gilles,

On Mon, Dec 01, 2014 at 11:03:54PM +0100, Gilles Caulier wrote:
> UUID is used to identify a disk, especially with removable media.

I guess I can understand there's a need for UUID for removable media
(I'm not really using them, so I'm just extrapolating the need...?)

But on a local system, why is there a need for both the UUID of the disk
the collection is on and the path of the collection? Why Digikam has to
identify the disk? Doesn't the path of the collection sufficiently
identifies it?

 Jonathan

> Gilles Caulier
>
> 2014-12-01 21:39 GMT+01:00 Jonathan Ballet <[hidden email]>:
> > I would be happy to try to propose a patch to remove this from Digikam,
> > but I would have liked to know first why there was such an UUID stored
> > (I guess there's a good reason?) and if there was a chance for a patch
> > to be accepted...
> >
> >  Jonathan
> >
> >
> > On Mon, Dec 01, 2014 at 08:25:39PM +0000, 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
> > _______________________________________________
> > Digikam-users mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

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

[Jonathan Ballet]

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
> >>>[hidden email]
> >>>https://mail.kde.org/mailman/listinfo/digikam-users
> >>_______________________________________________
> >>Digikam-users mailing list
> >>[hidden email]
> >>https://mail.kde.org/mailman/listinfo/digikam-users
> >
> >_______________________________________________
> >Digikam-users mailing list
> >[hidden email]
> >https://mail.kde.org/mailman/listinfo/digikam-users
> >
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

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

[Gilles Caulier-4]

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 <[hidden email]>:

> 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
>> >>>[hidden email]
>> >>>https://mail.kde.org/mailman/listinfo/digikam-users
>> >>_______________________________________________
>> >>Digikam-users mailing list
>> >>[hidden email]
>> >>https://mail.kde.org/mailman/listinfo/digikam-users
>> >
>> >_______________________________________________
>> >Digikam-users mailing list
>> >[hidden email]
>> >https://mail.kde.org/mailman/listinfo/digikam-users
>> >
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

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

I have also had success with simply moving all my shots around, and having them found (on the same machine).

UUID (in this case) is used to identify *filesystem* not physical disk - I can see no real reason for it here. I like the suggestion of storing only the relative path - might make it more portable for those who move between machines.
Absolute paths might have similar issues to UUID, if to a somewhat less extent.

S

--------------------------------------------
On Wed, 3/12/14, 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.

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

[Andrew Goodbody]

Hi Gilles,

The detection of the missing albumRoot does not adequately cover the
case where the same image files are regularly accessed from more than
one computer where the mount paths are different out of choice or
necessity eg Windows vs Linux.

So yes there is a need for a GUI interface for this although it may or
may not be best placed where you describe.

An alternative solution would be, as I suggested, to have the albumRoot
information in the digikamrc file so that it is only associated with the
machine that is running that instance of digikam which would match the
information that it contains.

Andrew

On 03/12/14 09:51, 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 <[hidden email]>:
>> 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
>>>>>> [hidden email]
>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>> _______________________________________________
>>>>> Digikam-users mailing list
>>>>> [hidden email]
>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>
>>>> _______________________________________________
>>>> Digikam-users mailing list
>>>> [hidden email]
>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>
>>> _______________________________________________
>>> Digikam-users mailing list
>>> [hidden email]
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

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

[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 <[hidden email]>:
> > 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
> >> >>>[hidden email]
> >> >>>https://mail.kde.org/mailman/listinfo/digikam-users
> >> >>_______________________________________________
> >> >>Digikam-users mailing list
> >> >>[hidden email]
> >> >>https://mail.kde.org/mailman/listinfo/digikam-users
> >> >
> >> >_______________________________________________
> >> >Digikam-users mailing list
> >> >[hidden email]
> >> >https://mail.kde.org/mailman/listinfo/digikam-users
> >> >
> >> _______________________________________________
> >> Digikam-users mailing list
> >> [hidden email]
> >> https://mail.kde.org/mailman/listinfo/digikam-users
> > _______________________________________________
> > Digikam-users mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

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

[Jürgen Blumenschein]

-----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 <[hidden email]>:
>>> 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 [hidden email]
>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>> _______________________________________________
>>>>>> Digikam-users mailing list [hidden email]
>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>
>>>>> _______________________________________________
>>>>> Digikam-users mailing list [hidden email]
>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>
>>>> _______________________________________________
>>>> Digikam-users mailing list [hidden email]
>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>> _______________________________________________ Digikam-users
>>> mailing list [hidden email]
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>> _______________________________________________ Digikam-users
>> mailing list [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________ Digikam-users
> mailing list [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

- --
Jürgen Blumenschein, eMail: [hidden email]
Homepage: http://huntington-info.eu/
Am Quartus 17
D-44149 Dortmund
Tel.: [phone], Fax: [phone]
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-----
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jonathan Ballet]

Hi Jürgen,

I'm currently testing the fix I was talking in a previous mail (see
http://mail.kde.org/pipermail/digikam-users/2014-December/020408.html),
I'll let you know how it goes :)

 Jonathan

On Thu, Dec 04, 2014 at 10:31:24AM +0100, Jürgen Blumenschein wrote:

> -----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 <[hidden email]>:
> >>> 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 [hidden email]
> >>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
> >>>>>> _______________________________________________
> >>>>>> Digikam-users mailing list [hidden email]
> >>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
> >>>>>
> >>>>> _______________________________________________
> >>>>> Digikam-users mailing list [hidden email]
> >>>>> https://mail.kde.org/mailman/listinfo/digikam-users
> >>>>>
> >>>> _______________________________________________
> >>>> Digikam-users mailing list [hidden email]
> >>>> https://mail.kde.org/mailman/listinfo/digikam-users
> >>> _______________________________________________ Digikam-users
> >>> mailing list [hidden email]
> >>> https://mail.kde.org/mailman/listinfo/digikam-users
> >> _______________________________________________ Digikam-users
> >> mailing list [hidden email]
> >> https://mail.kde.org/mailman/listinfo/digikam-users
> > _______________________________________________ Digikam-users
> > mailing list [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users
> >
>
>
> - --
> Jürgen Blumenschein, eMail: [hidden email]
> Homepage: http://huntington-info.eu/
> Am Quartus 17
> D-44149 Dortmund
> Tel.: [phone], Fax: [phone]
> 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-----
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

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