![]() 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 …ĭigging further into the “The Linux Documentation Project” – TLDP – “Linux Filesystem Hierarchy”: – 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). So all my data to one easy to backup volume. The folder /usr/local is actually a bind mount of /home/local. I aim to keep all my stuff in /home or /usr/local. 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. 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). 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. Eventually I bought a 2 TB SSD which could easily fit my photos, the database, and all my other accumulated non-photography stuff. 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. I have digikam using mariadb with the database stored in a folder in my home directory which is on SSD. (In the event of a catastrophic loss of your digikam database, you can rebuild it from the image exif data).Īt the end of the day though, they’re your images, you need to decide how to catalogue them… 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…”. It would be better to, if possible, “get it right” from the start, rather than to make extensive changes later. ![]() Perhaps play around for a little while until you find the “best” solution for your own needs. The hierarchy for my personal stuff is Subject/Year/Month, that for the client images simply Year/Client-Ref.ĭigiKam itself has quite good searching capabilities, and you also have the ability to apply (searchable) tags to images. I use digiKam for both my own personal photographs and those of clients (I supplement my income with wedding and event photography). 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. Think perhaps how you would arrange your photographs if you were doing it manually. … where should I start, particularly with the folder structure? Year>Month>file date? Web Albums are served locally by Apache: Okt 19:52 won’t want to load the above from NAS. Okt 19:51 /home/Albums/Bilder/similarity.db Okt 19:51 /home/Albums/Bilder/recognition.db Okt 19:51 /home/Albums/Bilder/digikam4.db **174G base: ll -h /home/Albums/Bilder/*db Storage is a folder in /home on a fast SSD: du -hd0 /home/Albums/Bilder/20* It is recommended that I use a symlink for the sqlite database file. My second question refers to the FAQ and possible troubles with locking when working with album on a network share. Also what ownership and permissions should I use for the digiKam database folder here? I could create that directory but I suspect there is a preferred alternative and seek advice on that please. Interesting but there is no /var/local/ directory in Tumbleweed at present. 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. 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. Using KDE desktop and have just installed digiKam but I need some advice please with the initial setup.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |