Sharing digiKam between Windows and Linux (no network, same machine)

[mik.clucas]

I'm not a fan of putting metadata in with the picture and I'm not sure whether this woll also work with raw files. But if you can put the db file on a share it could work fine or do you have to use a remote db server?


Sent from my Samsung device

-------- Original message --------
From: Andrey Goreev <aegoreev at gmail.com> 
Date: 23/02/2017  14:14  (GMT+01:00) 
To: digiKam - Home Manage your photographs as a professional with the power of open source <digikam-users at kde.org> 
Subject: Re: Sharing digiKam between Windows and Linux (no network, same machine) 

It depends on where you store the metadata.
If you write it to the jpgs, yes your method will work. If you store it in the database only you should share the .db file
Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: "mik.clucas" <mik.clucas at bluewin.ch> Date: 2017-02-23  5:52 AM  (GMT-07:00) To: daniel bip <daniel.mail.public at gmail.com>, digiKam - Home Manage your photographs as a professional with the power of open source <digikam-users at kde.org> Subject: Re: Sharing digiKam between Windows and Linux (no network, same machine) 

    
Hi DanielI also would like to use dk on more than 1 workstation. Not only the images but also the metdata(face detection, tags and flags etc). Does using a shared network location also share the dk database and metadata?
Best regardsMik

-------- Original message --------
From: daniel bip <daniel.mail.public at gmail.com> 
Date: 23/02/2017  12:41  (GMT+01:00) 
To: digiKam - Home Manage your photographs as a professional with the power of open source <digikam-users at kde.org> 
Subject: Re: Sharing digiKam between Windows and Linux (no network, same machine) 

Hi there,

What I personally did at the end was loading the library locally (Settings > Collections > Local Collections) from one of the instances (Windows) and then loading it shared (Settings > Collections > Collections on Network Shares) from the other instance (Ubuntu). Works well for me, no problems when changing from one instance to the other.

Hope it helps.

BR,


d.



On 22 February 2017 at 19:49, Shlomi Vaknin <shlomivaknin at gmail.com> wrote:
Hi, I actually have the same problem. at Andrey, I tried that, but lots of items did not pass (probably were stored in the DB), such as tags, descriptions etc.
Perhaps I am missing something simple, or is there another way?
Thanks!
On Fri, Feb 17, 2017 at 7:25 AM, Andrey Goreev <aegoreev at gmail.com> wrote:
I have just added the same collection twice. One was d:\Pictures while the other one was /media/d_drive/pictures. Worked for me.


Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: daniel bip <daniel.mail.public at gmail.com> Date: 2017-02-17  3:36 AM  (GMT-07:00) To: digikam-users at kde.org Subject: Sharing digiKam between Windows and Linux (no network, same machine) 
Hi there,

I've been using digiKam for Windows for a long but I find it quite slow and buggy and decided to move to Linux, so I installed a virtual machine in the very same computer and tried to access the very same DB and storing-directories from both "sides".

But when I launch digiKam from Linux it tells me that it can't find the location of the pictures. Once launched it displays stars, tags, and even thumbnails but it can't open pictures, as it can't find them in the HD. My guess is that digiKam can't find them because the information in the DB regarding the location is Windows-styled, and those directories from Linux are structured differently (ie: C:\fotos\ for Windows and /media/sd_D_DRIVE/ for Linux).

Can someone point me how to setup the DB in order to be able to open digiKam from Windows and Linux with the same config files? If possible...

If not, how do you recommend me to set everything up in order to be able to open from both sides?

Thanks in advance.

BR,


d.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20170223/9dc1ab12/attachment.html>