Shortcut to add a Tag

[Henrique Santos Fernandes]

Hello,

I am trying to asign the a letter to a tag shortcut, but i does not seens possible.

I can only use combinations of ctrl + lettler or Alt + letter etc.

Can anyone confirm if is able to set only a letter to tag a picture?

Go to Tags, Proprieties and try to set a Shortcut

It would be very nice if i could set only a letter to Tag a picture!

Like the inicials of Persons Name. ( i would set shortcuts for every event, so i could use to tag realy quicly those images

Thanks

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

[Henrique Santos Fernandes]

Hello again,

I just found an way to crash digikam 4.7 archlinux

And i can set the tag to a letter at same time.

Step to Reproduce:

Go to a tag, set a shotcut to it , as example:  alt + t

Now go at digikam shortcut settings, 

There is now a new shortcut called: 

Add tag "Sometag" 

Now you edit this shortcut to a custom shortcut entry like the leter "a" 

Digikam crashes, but the shortcut now is save and you can use it.

Always reproduceble.

The step names may differ cause i use Digikam in Portuguese.

Will now add this bug to tracker.

Em ter, 17 de mar de 2015 às 22:43, Henrique Santos Fernandes <[hidden email]> escreveu:

Hello,

I am trying to asign the a letter to a tag shortcut, but i does not seens possible.

I can only use combinations of ctrl + lettler or Alt + letter etc.

Can anyone confirm if is able to set only a letter to tag a picture?

Go to Tags, Proprieties and try to set a Shortcut

It would be very nice if i could set only a letter to Tag a picture!

Like the inicials of Persons Name. ( i would set shortcuts for every event, so i could use to tag realy quicly those images

Thanks

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

[Henrique Santos Fernandes]

Hope that helps:

https://bugs.kde.org/show_bug.cgi?id=345288

Em ter, 17 de mar de 2015 às 22:49, Henrique Santos Fernandes <[hidden email]> escreveu:

Hello again,

I just found an way to crash digikam 4.7 archlinux

And i can set the tag to a letter at same time.

Step to Reproduce:

Go to a tag, set a shotcut to it , as example:  alt + t

Now go at digikam shortcut settings, 

There is now a new shortcut called: 

Add tag "Sometag" 

Now you edit this shortcut to a custom shortcut entry like the leter "a" 

Digikam crashes, but the shortcut now is save and you can use it.

Always reproduceble.

The step names may differ cause i use Digikam in Portuguese.

Will now add this bug to tracker.

Em ter, 17 de mar de 2015 às 22:43, Henrique Santos Fernandes <[hidden email]> escreveu:

Hello,

I am trying to asign the a letter to a tag shortcut, but i does not seens possible.

I can only use combinations of ctrl + lettler or Alt + letter etc.

Can anyone confirm if is able to set only a letter to tag a picture?

Go to Tags, Proprieties and try to set a Shortcut

It would be very nice if i could set only a letter to Tag a picture!

Like the inicials of Persons Name. ( i would set shortcuts for every event, so i could use to tag realy quicly those images

Thanks

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

[Florian Hennig]

Hey guys!

I'm looking for the best way to move my entire collection to a new
place, because I'm running out of space at my HDD. So I bought a new one
and inserted into my Computer but now I don't know how to move all
pictures to the new disc.

Method 1:
Use a filemanager for moving all files to the new place and afterwards
tell digikam to add a new libary and delete the old one

Method 2:
Use digikam for moving the files to the new disk.

I have about 20.000 images in the current collection, folders sorted by
date in the ISO format.


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

[Henrique Santos Fernandes]

I am not sure, but i suppose using digikam to move images would be better.

I think the only "problem" of this, is that digikam first copies and than deletes the old album.

I've had the same isses, so i moved around files in digikam, it took a while.. at least there is a progress bar!

Moving the foldes with a filemanager may result in lost tags.. if they are not stored in files.. happens with videos and if you have not set the option to save metadata in images!

Hope i did som help.

I would wait for someone with more experience to answer anyway!

Em seg, 23 de mar de 2015 às 06:14, Florian Hennig <[hidden email]> escreveu:

Hey guys!

I'm looking for the best way to move my entire collection to a new
place, because I'm running out of space at my HDD. So I bought a new one
and inserted into my Computer but now I don't know how to move all
pictures to the new disc.

Method 1:
Use a filemanager for moving all files to the new place and afterwards
tell digikam to add a new libary and delete the old one

Method 2:
Use digikam for moving the files to the new disk.

I have about 20.000 images in the current collection, folders sorted by
date in the ISO format.


Thanks for helping,
Flo
_______________________________________________
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

[tosca]

Metadata are written to files if you choose so: see different options the Configuration Menu.

In any case, they are in Digikam database, that is not necessary on the same drive as the actual files. For example, I have almost all my pictures on external drives, but the database remains in my user folder on the internal drive; and Digikam has always access to it, whatever external drive is plugged in or not.

As for the complete move of your collections, I have always done this outside Digikam, with my usual file manager. This is much faster as Digikam doesn't try to keep track of any individual modification. And anyway, it will check the entire collections on your new drive.

Marie-Noëlle

2015-03-23 13:40 GMT+01:00 Henrique Santos Fernandes <[hidden email]>:

I am not sure, but i suppose using digikam to move images would be better.

I think the only "problem" of this, is that digikam first copies and than deletes the old album.

I've had the same isses, so i moved around files in digikam, it took a while.. at least there is a progress bar!

Moving the foldes with a filemanager may result in lost tags.. if they are not stored in files.. happens with videos and if you have not set the option to save metadata in images!

Hope i did som help.

I would wait for someone with more experience to answer anyway!

Em seg, 23 de mar de 2015 às 06:14, Florian Hennig <[hidden email]> escreveu:

Hey guys!

I'm looking for the best way to move my entire collection to a new
place, because I'm running out of space at my HDD. So I bought a new one
and inserted into my Computer but now I don't know how to move all
pictures to the new disc.

Method 1:
Use a filemanager for moving all files to the new place and afterwards
tell digikam to add a new libary and delete the old one

Method 2:
Use digikam for moving the files to the new disk.

I have about 20.000 images in the current collection, folders sorted by
date in the ISO format.


Thanks for helping,
Flo
_______________________________________________
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

[Chris Green]

Marie-Noëlle Augendre <[hidden email]> wrote:
>
> Metadata are written to files if you choose so: see different options the
> Configuration Menu.
>
I think you *must* do this, write metadata to files, see below.

> In any case, they are in Digikam database, that is not necessary on the
> same drive as the actual files. For example, I have almost all my pictures
> on external drives, but the database remains in my user folder on the
> internal drive; and Digikam has always access to it, whatever external
> drive is plugged in or not.
>
Yes, but if you move the pictures the database will no longer be valid
and Digikam will reconstruct it, losing all the metadata in the
database unless it has been written to file as well.

(I really cannot understand why anyone would ever *not* write the
metadata to file)


> As for the complete move of your collections, I have always done this
> outside Digikam, with my usual file manager. This is much faster as Digikam
> doesn't try to keep track of any individual modification. And anyway, it
> will check the entire collections on your new drive.
>
Yes, absolutely agree, as I'm a command line person I'd use rsync or
even just cp.

--
Chris Green
·

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

[David Lindblad]

Hi!

måndagen den 23 mars 2015 19.11.05 skrev  [hidden email]:
> Marie-Noëlle Augendre <[hidden email]> wrote:
> > Metadata are written to files if you choose so: see different options the
> > Configuration Menu.
>
> I think you *must* do this, write metadata to files, see below.

I do not think you must write to the file but you can use sidecar instead or as
complement. An .xmp file with metadata that can be copied to a new location and
enterped by DK.

>
> > In any case, they are in Digikam database, that is not necessary on the
> > same drive as the actual files. For example, I have almost all my pictures
> > on external drives, but the database remains in my user folder on the
> > internal drive; and Digikam has always access to it, whatever external
> > drive is plugged in or not.
>
> Yes, but if you move the pictures the database will no longer be valid
> and Digikam will reconstruct it, losing all the metadata in the
> database unless it has been written to file as well.
>
> (I really cannot understand why anyone would ever *not* write the
> metadata to file)

DK do not handle writing metadata to some files, .CR2 par example.

>
> > As for the complete move of your collections, I have always done this
> > outside Digikam, with my usual file manager. This is much faster as
> > Digikam
> > doesn't try to keep track of any individual modification. And anyway, it
> > will check the entire collections on your new drive.
>
> Yes, absolutely agree, as I'm a command line person I'd use rsync or
> even just cp.
//David
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Daniel Bauer-2]

Am 23.03.2015 um 20:11 schrieb [hidden email]:
>
> (I really cannot understand why anyone would ever *not* write the
> metadata to file)
>

This is not on the topic of the thread, but there a many reasons NOT to
write metadata to files.

I don't want to give my clients photos with my personal evaluation nor
with the indexing keywords under which I catalog them. I don't want
clients or models real names appear in images.

If I'd have tags in the images meta data I'd always have to be VERY
careful to strip them before delivery or upload on any website. I'm sure
I'd forget it from time to time or upload a tagged version instead of a
stripped one. This could have consequences...

So this is ONE reason not to have tags in image files. For sure many
more exist. For sure also many reasons exist to have them written to the
files and it is very good, that it is possible for those to whom it
serves. I for my part am happy that I can choose not to save my tages in
the images...

Have a beautiful night.

Daniel



--
Daniel Bauer photographer Basel Barcelona
http://www.daniel-bauer.com
room in Barcelona: https://www.airbnb.es/rooms/2416137
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Chris Green]

David Lindblad <[hidden email]> wrote:

> Hi!
>
> måndagen den 23 mars 2015 19.11.05 skrev  [hidden email]:
> > Marie-Noëlle Augendre <[hidden email]> wrote:
> > > Metadata are written to files if you choose so: see different options the
> > > Configuration Menu.
> >
> > I think you *must* do this, write metadata to files, see below.
>
> I do not think you must write to the file but you can use sidecar instead or as
> complement. An .xmp file with metadata that can be copied to a new location and
> enterped by DK.
>

Yes, I guess that's OK too, just don't have the metadata in the
Digikam database, it will be lost.

> >
> > > In any case, they are in Digikam database, that is not necessary on the
> > > same drive as the actual files. For example, I have almost all my pictures
> > > on external drives, but the database remains in my user folder on the
> > > internal drive; and Digikam has always access to it, whatever external
> > > drive is plugged in or not.
> >
> > Yes, but if you move the pictures the database will no longer be valid
> > and Digikam will reconstruct it, losing all the metadata in the
> > database unless it has been written to file as well.
> >
> > (I really cannot understand why anyone would ever *not* write the
> > metadata to file)
>
> DK do not handle writing metadata to some files, .CR2 par example.

Well that's a big problem then IMHO.

--
Chris Green
·

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

[Chris Green]

Daniel Bauer <[hidden email]> wrote:

>
>
> Am 23.03.2015 um 20:11 schrieb [hidden email]:
> >
> > (I really cannot understand why anyone would ever *not* write the
> > metadata to file)
> >
>
> This is not on the topic of the thread, but there a many reasons NOT to
> write metadata to files.
>
> I don't want to give my clients photos with my personal evaluation nor
> with the indexing keywords under which I catalog them. I don't want
> clients or models real names appear in images.
>
> If I'd have tags in the images meta data I'd always have to be VERY
> careful to strip them before delivery or upload on any website. I'm sure
> I'd forget it from time to time or upload a tagged version instead of a
> stripped one. This could have consequences...
>
> So this is ONE reason not to have tags in image files. For sure many
> more exist. For sure also many reasons exist to have them written to the
> files and it is very good, that it is possible for those to whom it
> serves. I for my part am happy that I can choose not to save my tages in
> the images...
>

All very true but it's very, very risky I think.  You are always at
risk of losing the metadata.

As far as I understand how things work if your main digikam store
fails in any way you will lose the metadata if it's stored only in the
database.  This is because Digikam will reconstruct the database when
you restore from backup.  Backing up the database file doesn't help
because it won't work on a new disk drive, Digikam rebuilds it. (Well
it might work if you restore to exactly the same place on the same
disk drive but that assumes the disk drive hasn't failed)

There needs to be a way to copy a collection of Digikam images and its
database in a way that allows copying the metadata from one database
file to another.  At present I think the only way to copy is to write
all the metadata to file, then copy all the image files, then recreate
the database from the metadata in the files.

--
Chris Green
·

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

[Gilles Caulier-4]

2015-03-23 23:19 GMT+01:00  <[hidden email]>:

> David Lindblad <[hidden email]> wrote:
>> Hi!
>>
>> måndagen den 23 mars 2015 19.11.05 skrev  [hidden email]:
>> > Marie-Noëlle Augendre <[hidden email]> wrote:
>> > > Metadata are written to files if you choose so: see different options the
>> > > Configuration Menu.
>> >
>> > I think you *must* do this, write metadata to files, see below.
>>
>> I do not think you must write to the file but you can use sidecar instead or as
>> complement. An .xmp file with metadata that can be copied to a new location and
>> enterped by DK.
>>
> Yes, I guess that's OK too, just don't have the metadata in the
> Digikam database, it will be lost.
>
>> >
>> > > In any case, they are in Digikam database, that is not necessary on the
>> > > same drive as the actual files. For example, I have almost all my pictures
>> > > on external drives, but the database remains in my user folder on the
>> > > internal drive; and Digikam has always access to it, whatever external
>> > > drive is plugged in or not.
>> >
>> > Yes, but if you move the pictures the database will no longer be valid
>> > and Digikam will reconstruct it, losing all the metadata in the
>> > database unless it has been written to file as well.
>> >
>> > (I really cannot understand why anyone would ever *not* write the
>> > metadata to file)
>>
>> DK do not handle writing metadata to some files, .CR2 par example.
>
> Well that's a big problem then IMHO.

not digiKam, but Exiv2 lib.

XMP sidecar is the universal alternative. After all, RAW files must
still read only as negatives...

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

[Gilles Caulier-4]

2015-03-23 23:36 GMT+01:00  <[hidden email]>:

> Daniel Bauer <[hidden email]> wrote:
>>
>>
>> Am 23.03.2015 um 20:11 schrieb [hidden email]:
>> >
>> > (I really cannot understand why anyone would ever *not* write the
>> > metadata to file)
>> >
>>
>> This is not on the topic of the thread, but there a many reasons NOT to
>> write metadata to files.
>>
>> I don't want to give my clients photos with my personal evaluation nor
>> with the indexing keywords under which I catalog them. I don't want
>> clients or models real names appear in images.
>>
>> If I'd have tags in the images meta data I'd always have to be VERY
>> careful to strip them before delivery or upload on any website. I'm sure
>> I'd forget it from time to time or upload a tagged version instead of a
>> stripped one. This could have consequences...
>>
>> So this is ONE reason not to have tags in image files. For sure many
>> more exist. For sure also many reasons exist to have them written to the
>> files and it is very good, that it is possible for those to whom it
>> serves. I for my part am happy that I can choose not to save my tages in
>> the images...
>>
> All very true but it's very, very risky I think.  You are always at
> risk of losing the metadata.
>
> As far as I understand how things work if your main digikam store
> fails in any way you will lose the metadata if it's stored only in the
> database.  This is because Digikam will reconstruct the database when
> you restore from backup.  Backing up the database file doesn't help
> because it won't work on a new disk drive, Digikam rebuilds it. (Well
> it might work if you restore to exactly the same place on the same
> disk drive but that assumes the disk drive hasn't failed)
>
> There needs to be a way to copy a collection of Digikam images and its
> database in a way that allows copying the metadata from one database
> file to another.  At present I think the only way to copy is to write
> all the metadata to file, then copy all the image files, then recreate
> the database from the metadata in the files.
>

Not at all..

digiKam identify collection from disk using UUID. This ID is stored in DB.

If you change disk where collection are stored, at next startup
digiKam will not find old disk and will ask to rellocate collection to
new disk. If you use same path than older disk mount point, digiKam
will found it quickly. You just need to validate. It take 10 s to
review whole collection storage.

That all.

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

[Chris Green]

Gilles Caulier <[hidden email]> wrote:

> > All very true but it's very, very risky I think.  You are always at
> > risk of losing the metadata.
> >
> > As far as I understand how things work if your main digikam store
> > fails in any way you will lose the metadata if it's stored only in the
> > database.  This is because Digikam will reconstruct the database when
> > you restore from backup.  Backing up the database file doesn't help
> > because it won't work on a new disk drive, Digikam rebuilds it. (Well
> > it might work if you restore to exactly the same place on the same
> > disk drive but that assumes the disk drive hasn't failed)
> >
> > There needs to be a way to copy a collection of Digikam images and its
> > database in a way that allows copying the metadata from one database
> > file to another.  At present I think the only way to copy is to write
> > all the metadata to file, then copy all the image files, then recreate
> > the database from the metadata in the files.
> >
>
> Not at all..
>
> digiKam identify collection from disk using UUID. This ID is stored in DB.
>

Which is why, by default, if you move a digikam hierarchy it rebuilds
the database.


> If you change disk where collection are stored, at next startup
> digiKam will not find old disk and will ask to rellocate collection to
> new disk. If you use same path than older disk mount point, digiKam
> will found it quickly. You just need to validate. It take 10 s to
> review whole collection storage.
>
I've not seen this happen when I have copied a digikam hierarchy.
When I copied mine from one place to another (everything including the
database) digikam *always* rebuilt the database.

In my case I was copying digikam from /home/chris/pictures on one
computer to /home/chris/pictures on another computer.  I actually
wanted to mirror the collection but, as I said, digikam always
insisted on rebuilding the database (which took several hours).

If there is a way of doing this I'd love to know because it would make
my life a whole lot easier!

--
Chris Green
·

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

[Gilles Caulier-4]

2015-03-24 10:50 GMT+01:00  <[hidden email]>:

> Gilles Caulier <[hidden email]> wrote:
>> > All very true but it's very, very risky I think.  You are always at
>> > risk of losing the metadata.
>> >
>> > As far as I understand how things work if your main digikam store
>> > fails in any way you will lose the metadata if it's stored only in the
>> > database.  This is because Digikam will reconstruct the database when
>> > you restore from backup.  Backing up the database file doesn't help
>> > because it won't work on a new disk drive, Digikam rebuilds it. (Well
>> > it might work if you restore to exactly the same place on the same
>> > disk drive but that assumes the disk drive hasn't failed)
>> >
>> > There needs to be a way to copy a collection of Digikam images and its
>> > database in a way that allows copying the metadata from one database
>> > file to another.  At present I think the only way to copy is to write
>> > all the metadata to file, then copy all the image files, then recreate
>> > the database from the metadata in the files.
>> >
>>
>> Not at all..
>>
>> digiKam identify collection from disk using UUID. This ID is stored in DB.
>>
> Which is why, by default, if you move a digikam hierarchy it rebuilds
> the database.

no, not in this case.

Typical use case that i do recently : one SSD 500Go changed as SSD 1To
to store whole collection. Both disks use Ext4.

1/ I copied data from 500Go SSD to 1To SSD
2/ I removed 500Go SSD
3/ Mount point of 1To SSD is the same than 500Go SSD : /mnt/data
4/ I started digiKam
5/ 500Go SSD disapear and digiKam see it (through Solid interface)
6/ 1To SSD appears and digiKam detect it.
7/ quickly at startup a dialog will appear to inform user about change
and ask to relocate DB information about missing disk to new one. A
question is ask for each root collection setup in digiKam. In fact the
new UUID from new disk replace old UUID in DB.
8/ No scan is performed. No DB rebuild. digiKam start quickly.

Operation duration : 10-30 seconds, depending of root collections
configured in old disk.

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

[Flo-2]

Thanks a lot for all the answers!                                              
                                                                               
So if I use the same mount point (in my case /home/flo/Pictures) digikam will
keep the database entries?
Or do I have to change the UUID manually and if so how to do that?              
                                                                               
Greetings,                                                                      
Flo

On Tuesday, March 24, 2015 09:50:36 AM [hidden email] wrote:

> Gilles Caulier <[hidden email]> wrote:
> > > All very true but it's very, very risky I think.  You are always at
> > > risk of losing the metadata.
> > >
> > > As far as I understand how things work if your main digikam store
> > > fails in any way you will lose the metadata if it's stored only in the
> > > database.  This is because Digikam will reconstruct the database when
> > > you restore from backup.  Backing up the database file doesn't help
> > > because it won't work on a new disk drive, Digikam rebuilds it. (Well
> > > it might work if you restore to exactly the same place on the same
> > > disk drive but that assumes the disk drive hasn't failed)
> > >
> > > There needs to be a way to copy a collection of Digikam images and its
> > > database in a way that allows copying the metadata from one database
> > > file to another.  At present I think the only way to copy is to write
> > > all the metadata to file, then copy all the image files, then recreate
> > > the database from the metadata in the files.
> >
> > Not at all..
> >
> > digiKam identify collection from disk using UUID. This ID is stored in DB.
>
> Which is why, by default, if you move a digikam hierarchy it rebuilds
> the database.
>
> > If you change disk where collection are stored, at next startup
> > digiKam will not find old disk and will ask to rellocate collection to
> > new disk. If you use same path than older disk mount point, digiKam
> > will found it quickly. You just need to validate. It take 10 s to
> > review whole collection storage.
>
> I've not seen this happen when I have copied a digikam hierarchy.
> When I copied mine from one place to another (everything including the
> database) digikam *always* rebuilt the database.
>
> In my case I was copying digikam from /home/chris/pictures on one
> computer to /home/chris/pictures on another computer.  I actually
> wanted to mirror the collection but, as I said, digikam always
> insisted on rebuilding the database (which took several hours).
>
> If there is a way of doing this I'd love to know because it would make
> my life a whole lot easier!

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

[Chris Green]

Gilles Caulier <[hidden email]> wrote:

> 2015-03-24 10:50 GMT+01:00  <[hidden email]>:
> > Gilles Caulier <[hidden email]> wrote:
> >> > All very true but it's very, very risky I think.  You are always at
> >> > risk of losing the metadata.
> >> >
> >> > As far as I understand how things work if your main digikam store
> >> > fails in any way you will lose the metadata if it's stored only in the
> >> > database.  This is because Digikam will reconstruct the database when
> >> > you restore from backup.  Backing up the database file doesn't help
> >> > because it won't work on a new disk drive, Digikam rebuilds it. (Well
> >> > it might work if you restore to exactly the same place on the same
> >> > disk drive but that assumes the disk drive hasn't failed)
> >> >
> >> > There needs to be a way to copy a collection of Digikam images and its
> >> > database in a way that allows copying the metadata from one database
> >> > file to another.  At present I think the only way to copy is to write
> >> > all the metadata to file, then copy all the image files, then recreate
> >> > the database from the metadata in the files.
> >> >
> >>
> >> Not at all..
> >>
> >> digiKam identify collection from disk using UUID. This ID is stored in DB.
> >>
> > Which is why, by default, if you move a digikam hierarchy it rebuilds
> > the database.
>
> no, not in this case.
>
> Typical use case that i do recently : one SSD 500Go changed as SSD 1To
> to store whole collection. Both disks use Ext4.
>
> 1/ I copied data from 500Go SSD to 1To SSD
> 2/ I removed 500Go SSD
> 3/ Mount point of 1To SSD is the same than 500Go SSD : /mnt/data
> 4/ I started digiKam
> 5/ 500Go SSD disapear and digiKam see it (through Solid interface)
> 6/ 1To SSD appears and digiKam detect it.
> 7/ quickly at startup a dialog will appear to inform user about change
> and ask to relocate DB information about missing disk to new one. A
> question is ask for each root collection setup in digiKam. In fact the
> new UUID from new disk replace old UUID in DB.
> 8/ No scan is performed. No DB rebuild. digiKam start quickly.
>
> Operation duration : 10-30 seconds, depending of root collections
> configured in old disk.
>

Well in my case it was simply:-

    rsync -a    /home/chris/pictures    laptop:/home/chris/pictures

and there was no way I could get the laptop to use the digikam
database file copied across, it *always* rebuilt it.

Is the database somehow referred to the mount point?  Could this could
be changed/relaxed so that it is possible to do what I want to do,
that is copy a digikam hierarchy from one computer to another easily?

--
Chris Green
·

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

[Remco Viëtor]

On Tuesday 24 March 2015 11:20:30 Gilles Caulier wrote:
> >> Not at all..
> >>
> >> digiKam identify collection from disk using UUID. This ID is stored in
DB.

> >>
> > Which is why, by default, if you move a digikam hierarchy it rebuilds
> > the database.
>
> no, not in this case.
>
> Typical use case that i do recently : one SSD 500Go changed as SSD 1To
> to store whole collection. Both disks use Ext4.
>
> 1/ I copied data from 500Go SSD to 1To SSD
> 2/ I removed 500Go SSD
> 3/ Mount point of 1To SSD is the same than 500Go SSD : /mnt/data
> 4/ I started digiKam
> 5/ 500Go SSD disapear and digiKam see it (through Solid interface)
> 6/ 1To SSD appears and digiKam detect it.
> 7/ quickly at startup a dialog will appear to inform user about change
> and ask to relocate DB information about missing disk to new one. A
> question is ask for each root collection setup in digiKam. In fact the
> new UUID from new disk replace old UUID in DB.
> 8/ No scan is performed. No DB rebuild. digiKam start quickly.
>
> Operation duration : 10-30 seconds, depending of root collections
> configured in old disk.

Just to make sure I understand this correctly.

We have two cases:
- if you move your collection to a new disk, and make sure that the
absolute path to the collection stays the same, Digikam will ask for
confirmation and just update the UUID

- if you move the collection in such a way that the absolute path to the
collection changes, Digikam will rescan all the images.

So what happens if you move the collection to a new disk, which goes to a
different mount point (so the absolute path to the colleciton changes)?
(Note that the collection no longer exists at the original path)

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

[Chris Green]

Remco Viëtor <[hidden email]> wrote:

> On Tuesday 24 March 2015 11:20:30 Gilles Caulier wrote:
> > >> Not at all..
> > >>
> > >> digiKam identify collection from disk using UUID. This ID is stored in
> DB.
> > >>
> > > Which is why, by default, if you move a digikam hierarchy it rebuilds
> > > the database.
> >
> > no, not in this case.
> >
> > Typical use case that i do recently : one SSD 500Go changed as SSD 1To
> > to store whole collection. Both disks use Ext4.
> >
> > 1/ I copied data from 500Go SSD to 1To SSD
> > 2/ I removed 500Go SSD
> > 3/ Mount point of 1To SSD is the same than 500Go SSD : /mnt/data
> > 4/ I started digiKam
> > 5/ 500Go SSD disapear and digiKam see it (through Solid interface)
> > 6/ 1To SSD appears and digiKam detect it.
> > 7/ quickly at startup a dialog will appear to inform user about change
> > and ask to relocate DB information about missing disk to new one. A
> > question is ask for each root collection setup in digiKam. In fact the
> > new UUID from new disk replace old UUID in DB.
> > 8/ No scan is performed. No DB rebuild. digiKam start quickly.
> >
> > Operation duration : 10-30 seconds, depending of root collections
> > configured in old disk.
> Just to make sure I understand this correctly.
>
> We have two cases:
> - if you move your collection to a new disk, and make sure that the
> absolute path to the collection stays the same, Digikam will ask for
> confirmation and just update the UUID
>
> - if you move the collection in such a way that the absolute path to the
> collection changes, Digikam will rescan all the images.
>
> So what happens if you move the collection to a new disk, which goes to a
> different mount point (so the absolute path to the colleciton changes)?
> (Note that the collection no longer exists at the original path)
>

The mount point doesn't appear in the path necessarily.  Most smallish
Linux systems are likely to have everything on / anyway.  The absolute
path when I did an rsync copy to my laptop was the same on the laptop
as it was on my desktop machine where I had copied it from.

/mnt/data is normally just a temporary mount point for external disks
such as eSata or USB drives, it's not where I would normally ever have
a digikam collection.  As I said my pictures are in ~/pictures which
on all my systems (and there are quite a few around my house and on
laptops) is always /home/chris/pictures.

The absolute path doesn't change and digikam *does* rebuild the
database, I've never seen otherwise.

--
Chris Green
·

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

[Gilles Caulier-4]

2015-03-24 17:03 GMT+01:00  <[hidden email]>:

> Remco Viëtor <[hidden email]> wrote:
>> On Tuesday 24 March 2015 11:20:30 Gilles Caulier wrote:
>> > >> Not at all..
>> > >>
>> > >> digiKam identify collection from disk using UUID. This ID is stored in
>> DB.
>> > >>
>> > > Which is why, by default, if you move a digikam hierarchy it rebuilds
>> > > the database.
>> >
>> > no, not in this case.
>> >
>> > Typical use case that i do recently : one SSD 500Go changed as SSD 1To
>> > to store whole collection. Both disks use Ext4.
>> >
>> > 1/ I copied data from 500Go SSD to 1To SSD
>> > 2/ I removed 500Go SSD
>> > 3/ Mount point of 1To SSD is the same than 500Go SSD : /mnt/data
>> > 4/ I started digiKam
>> > 5/ 500Go SSD disapear and digiKam see it (through Solid interface)
>> > 6/ 1To SSD appears and digiKam detect it.
>> > 7/ quickly at startup a dialog will appear to inform user about change
>> > and ask to relocate DB information about missing disk to new one. A
>> > question is ask for each root collection setup in digiKam. In fact the
>> > new UUID from new disk replace old UUID in DB.
>> > 8/ No scan is performed. No DB rebuild. digiKam start quickly.
>> >
>> > Operation duration : 10-30 seconds, depending of root collections
>> > configured in old disk.
>> Just to make sure I understand this correctly.
>>
>> We have two cases:
>> - if you move your collection to a new disk, and make sure that the
>> absolute path to the collection stays the same, Digikam will ask for
>> confirmation and just update the UUID
>>
>> - if you move the collection in such a way that the absolute path to the
>> collection changes, Digikam will rescan all the images.
>>
>> So what happens if you move the collection to a new disk, which goes to a
>> different mount point (so the absolute path to the colleciton changes)?
>> (Note that the collection no longer exists at the original path)
>>
> The mount point doesn't appear in the path necessarily.  Most smallish
> Linux systems are likely to have everything on / anyway.  The absolute
> path when I did an rsync copy to my laptop was the same on the laptop
> as it was on my desktop machine where I had copied it from.
>
> /mnt/data is normally just a temporary mount point for external disks
> such as eSata or USB drives, it's not where I would normally ever have
> a digikam collection.

No.

/mnt/data is dedicated to mount something in local or in remote,
registered in static to /etc/fstab. Mine, monted at startup :

/dev/sdd1 on /mnt/data2 type ext4 (rw,relatime,data=ordered)  <<= SSD 1Tb
/dev/mapper/vg--data-data on /mnt/data type ext4
(rw,relatime,data=ordered) <<= RAID HDD 16Tb

Removal media are mounted automatically on demand to /run
automatically by a dedicated service. For ex, my external USB3 2Tb
hard drive (NTFS) is mounted here :

/dev/sdm1 on /run/media/gilles/2TO_USB3 type fuseblk
(rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)

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