[digiKam-users] Sharing Collection Database

[Jack Haverty]

Another approach...  

I use DK on both Windows and Linux, with all photos stored on a NAS
accessible to both.   My "sharing collection" scheme has been to keep a
copy of the database on each machine, making a small change inside the
DK database file to get DK on each system to be able to find the photos.

The Linux system sees the photos as at /Alexandria/photo, where the
Windows system sees Z:\photo (or something like that).  After copying
the database file from one machine to another, I use a database editor
to modify the "specificPath" entries in the "AlbumRoots" table
appropriately.  The screenshot below is a capture of how it looks after
setting it up for use on Linux.

I only have one AlbumRoot; if you have more you'll need to change each
one.  But usually there aren't very many Album Roots I expect.    You
also of course have to be careful when you make changes to keep the
separate copies in sync.

Yes, it would be great to be able to do this inside DK rather than
"opening up the hood" to change the database file itself.   But it does
seem to work fine, at least for me.

/Jack

Using DB editor to change Album Root

On 8/3/20 1:06 AM, Nick Cross wrote:
>
>
> As a followup to this having read through the mailing lists and bug
> database I found a lot of hints in
> https://bugs.kde.org/show_bug.cgi?id=261277 and
> http://digikam.1695700.n4.nabble.com/digiKam-users-DigiKam-and-multiple-computers-best-practices-td4705570.html
>
> What I want is the ability to use the _same_ database (NOT at the same
> time) on either a Linux or Windows computer with different mount
> paths. I found that creating a 'network collection' *and* editing the
> database to change
>
> "networkshareid:?mountpath=/home/rnc/Insync/name1/Pictures"
> to
> "networkshareid:?mountpath=/home/rnc/Insync/name1/Pictures&mountpath=D:\name1\Pictures"
>
>
> seems to allow Digikam to transparently use either the Windows or
> Linux path depending on which is available.
>
> It would be great if there was an official UI for this - or is anyone
> aware of any existing ticket ?
>
>
> The only other issue is that the default Windows 10 codepage is I
> think 1532 (System?) and Fedora 32 is UTF-8. While these are not
> identical, in my case, none of the database album names contain
> non-ascii characters. I therefore get the the locale warning every
> single time. I don't think Windows 10 officially supports UTF-8 so my
> options are limited - suggestions appreciated!
>
> It would be great if there was a of dismissing the warning in the UI
> so it doesn't appear again. I think the related ticket is
> https://bugs.kde.org/show_bug.cgi?id=382362
>
>
> Thanks
>
> Nick
>
>
> On 29/07/2020 16:47, Nick Cross wrote:
>> Hi,
>>
>> I have my collection on my Linux machine that is synced via cloud
>> storage to my windows machine. I was wondering if there is any way of
>> 'sharing' the database - but given the problem that the base paths
>> are different (even if the paths _within_ the collection are not) I
>> can't see an obvious method.
>>
>> For instance - I have on Linux
>>
>> /home/rnc/Insync/name1/Pictures
>> /home/rnc/Insync/name2/Pictures
>> /home/rnc/Insync/name2/Photographs
>>
>> On Windows these appear as
>>
>> D:\name1\Photographs
>> D:\name2\Pictures
>> D:\name2\Pictures
>>
>> The problem is obviously the base paths are different. Adding them as
>> different removable collections means I get 'duplicates' within the
>> digikam interface.
>>
>> Is there any solution to this ( or an existing bug to vote upon ) ?
>>
>>
>> Alternatively, what exactly is stored within the database i.e. is it
>> - album locations, tags and labels? What does similarity.db and
>> recognition.db contain?  I was wondering if it might be feasible to
>> have 'database-win' and 'database-linux' depending upon the amount of
>> information recorded within it?
>>
>> Thanks
>>
>> Nick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20200811/f00ea437/attachment-0001.htm>