Using KDE desktop and have just installed digiKam but I need some advice please with the initial setup.
My intention is to use work with my picture library which is on a cloud drive but I shall probably have to relocate them to a NAS. The setup requires that the database files are stored on a local drive which is fine except that the digiKam manual suggests I save the database on /var/local/lib/digiKam. Interesting but there is no /var/local/ directory in Tumbleweed at present. I could create that directory but I suspect there is a preferred alternative and seek advice on that please. Also what ownership and permissions should I use for the digiKam database folder here?
My second question refers to the FAQ and possible troubles with locking when working with album on a network share. It is recommended that I use a symlink for the sqlite database file. What symlink and where?
Hi Paul,
Many thanks and understood. I think you may be able to help with my question about where to save the sqlite data as this is not NAS related, just me being ignorant. The initial setup in the app is no help at all as it offers the same directory as the data and the documentation offers /var/local/… which does not exist on my TW installation.
I tried to find the forum/list but the website link was dead last night. Will keep looking.
Many thanks again,
Budge
The reason I like keeping everything in or below ~/Photos/DigiKam/ is I use rsync to back up to an external drive without having to faff around with lots of “–include” and “–exclude” options…
Hi all and many thanks for the guidance. My initial excursion was from a laptop but I have now opted to use my main workstation hard drives and adopted a straight forward setup using my master media photos directory which has a few pictures in it already.
All good so far but what next I ask? This reminds me of a similar problem with tagging classical music, an exercise in cladistic taxonomy; where should I start, particularly with the folder structure? Year>Month>file date?
Will read the manual and ask if I get stuck.
Budge
Think perhaps how you would arrange your photographs if you were doing it manually. DigiKam allows Albums (Directories of images) to have Sub-Albums (Sub-directories of images), that may be useful in deciding the hierarchy of directory structure used.
I use digiKam for both my own personal photographs and those of clients (I supplement my income with wedding and event photography).
The hierarchy for my personal stuff is Subject/Year/Month, that for the client images simply Year/Client-Ref.
DigiKam itself has quite good searching capabilities, and you also have the ability to apply (searchable) tags to images.
Perhaps play around for a little while until you find the “best” solution for your own needs. It would be better to, if possible, “get it right” from the start, rather than to make extensive changes later.
One suggestion I would make is to ensure you allow digikam to write to the image exif data, Settings -> Configure digiKam -> Metadata -> Behaviour -> “Write this information…”. (In the event of a catastrophic loss of your digikam database, you can rebuild it from the image exif data).
At the end of the day though, they’re your images, you need to decide how to catalogue them…
My digikam db and all the pics are on remote NFS storage. The fact that digikam claims that this is unsupported does not mean it does not work. It does have a performance penalty especially when you do db heavy lifting like face recognition. NFSv3 was crawling but NFSv4 works okay-ish. I can live with that as it keeps everything in once place and accessible from all clients on my home network. There used to be an option to use a real RDBMS like mysql or postgres. I did try this once but then dropped it as the overhead of running the db server was more work than just waiting for sqlite.
/var/localVariable data for programs that are installed in /usr/local (i.e., programs that have been installed by the system administrator). Note that even locally installed programs should use the other /var directories if they are appropriate, e.g., /var/lock.
/usr/localThe place for locally installed software and other files. Distributions may not install anything in here. It is reserved solely for the use of the local administrator. This way he can be absolutely certain that no updates or upgrades to his distribution will overwrite any extra software he has installed locally.
I have absolutely no idea why the digiKam folks assume that, only administrators will be installing their packages and, that Distributions have not included their packages …
I have digikam using mariadb with the database stored in a folder in my home directory which is on SSD. I switched to mariadb on SSD when the photos on the disk grew beyond 500 GB and the scans for new items started to take a large amount of time. Eventually I bought a 2 TB SSD which could easily fit my photos, the database, and all my other accumulated non-photography stuff.
On each login (approximately once per day) I have a backup script that checks if digikam is running, if not it backs up the database folder and other config files to a tar. This helps if anything goes badly wrong with the database/config files (which has only ever happened once due to a mistake I made when playing with digikam settings). The backup script uses notify-send to inform the desktop that the backup is in progress or is being skipped due to to digikam being active - that way I only create consistent backups, and I won’t accidentally start digikam until the backup finishes.
I aim to keep all my stuff in /home or /usr/local. The folder /usr/local is actually a bind mount of /home/local. So all my data to one easy to backup volume. This is backed up to an online backup disk daily, and offline USB-disks weekly (the offlines are a set which are rotated out of the house). The OS is on it’s own SSD.
Which is almost the same with the caveat that, despite /var as such being defined as part of the “root” filesystem – not to be confused with the user “root” – it is recommended to move it out to it’s own partition to avoid issues around the partition holding the “root” filesystem running out of space …
Bottom line, the digiKam folks state that, the core engines of the application are the databases, which should be located on fast hardware such as an SSD …
Therefore, it makes sense to move the /var filesystem to a dedicated partition on an SSD, with enough free space for /var/local where the digiKam databases are located …
Further thanks to all who have contributed.
I am starting using the KISS principle using simple year/month directories/sub-directories as this is how the photos have been stored. The more I read the more work lies ahead and may have some more questions concerning directory structure but at least I can start to get the data in one place and will work on tagging when I have thought through the advice in the manual.
I note the comments on where to put the database files, /usr/local/ would be an option but at present they are in the same directory as the data, ie ~/Photos.
The manual has some information on using a Database on a server to enable network access. This would be the way to go for me in long term but not for a good while.
Many thanks for sharing the backup routines. Not quite there yet but working on it.
Very impressed with what I have seen and learnt so far so thanks again to all who have contributed so constructively.
I’m using year/geographical year/month/ etc. First always the year and then sub folders. The physical location of folders/pictures is on a NFS-share on a server. On the same server also the mariadb SQL. Easy to access from my different clients and my tablet even from outside(i-net) trow nextcloud witch using the same mariadb on that server so it was not to much extra work to set up the tables for digikam there.
For those wondering about /var/local/ on an SSD, the following recipe works:
[ul]
[li]System with the system directories on an SSD and rotating drives for home directories plus /var, /tmp and /srv … [/li][li]User “root” actions:[/li][LIST]
[li]On the system SSD create a directory for /var/local/ – name it however you like but, make sure that, the chosen name does not clash with any Linux system directory names … [/li][li]Within /var create a symbolic link: “ln --symbolic …/zVarLocal /var/local”. [/li][li]Create a directory “/var/local/digiKam”. [/li][li]Create a directory “/var/local/digiKam/«digiKam user»” and change the owner of that directory to that of the digiKam user. [/li][/ul]
[li]digiKam user actions:[/li][ul]
[li]Start digiKam. [/li][li]In the settings, select a new location for the Database → “/var/local/digiKam/«digiKam user»” – digiKam will ask if the Database should be copied to the new location or moved to the new location. [/li][/ul]
[/LIST]
Should also be OK if the photos being managed by digiKam are located on a NAS …
In respect to sub-folder organisation in recent years I settled on Pictures/Camera-ID/YYYY/YYYY_MM/YYYY_MM_DD/. The date-prefix repetition/redundancy makes mistakes less likely when scripting bulk operations. The extra redundancy isn’t an inconvenience because of shell tab-completion (zsh+Oh-My-Zsh).
On occasion I do keep both RAW and JPG, although mostly I’m happy to retain only the JPG. To prevent confusion and facilitate bulk operations on just RAW or just JPG, I split the bottom level between the two, so there would be a ~/Pictures/E-M1MarkIII/2020/2020_11/2020_11_06/JPG/ and ~/Pictures/E-M1MarkIII/2020/2020_11/2020_11_06/RAW/.
On I should mention I don’t actually use digikam to download the pictures from the camera. I have my own script that mounts/transfers/unmounts sd-card media. I’ve done this to speed up partial transfers in the situation where I’ve already accumulated many images on the sdcard and just want to transfer the ones not already transferred.
Hi
I have read the links about using mariadb and a network server. The descriptions are old. It was some release notes in late digikam 6-series that the use was suggested of tree tables for performance:
Core Db Name ->digikam
Thumbs Db Name->thumbnails
Face Db Name->recognition
And later;
Similarity Db name ->similarity
Hi and my thanks to all in helping me with my first excursion with digiKam.
I have been able to do a good deal of housework gathering most of my pictures from the last 50 years. Many are still being scanned but I have made a start.
I have done as suggested in keeping things simple as others have done above and have found the tools most helpful.
I think I probably will need a new NAS and I shall then look again at the database advice above but at the moment I only am working with a couple of thousand picture so all good and I think this thread should be closed.
