Version: 0.8.2 (using KDE KDE 3.5.5) Installed from: Ubuntu Packages OS: Linux Tempting to file this as a bug, but I'm sure the developers will classify it as a feature request... This is related to the following issues: http://bugs.kde.org/show_bug.cgi?id=116252 : failed to update db on nfs shares http://bugs.kde.org/show_bug.cgi?id=118543 : enable-nfs-hack no longer works http://bugs.kde.org/show_bug.cgi?id=122516 : Album Path cannot be on Network device (Unmounted) http://bugs.kde.org/show_bug.cgi?id=121005 : digikam won´t start when the album-path stays on nfs-volume http://bugs.kde.org/show_bug.cgi?id=129437 : wish: Album could point to network path. Now it's impossible to view photos from shared network drive. http://bugs.kde.org/show_bug.cgi?id=134594 : WISH: Independent database backend support for increased usability (MySQL/PostgreSQL etc) The frequent answer seems to be, read http://www.sqlite.org/faq.html#q7 Now, as an end user, I care little or none about the backend(s) used by digikam. All I want, is to be able to store my pictures on a network drive, so other machines can access the same picture collection. I understand that digikam keeps a database of the pictures, and that this database is now in sqlite. However, it should be REALLY EASY to provide e.g. a command-line option to store the database file in the user's home directory (even if the pictures themselves are on a network drive). This simple change should take care of the user's need, without requiring the developers to rewrite the database backend (which, obviously, is a major undertaking).
<<However, it should be REALLY EASY to provide e.g. a command-line option to store the database file in the user's home directory >> I agree. I would suggest to add 2 command-line options to start digikam : -f to specify the full path to digikam3.db -d to specify the full path to the albums root directory Use cases : - be able to have different independant collections (eg professional, personal, etc...) - be able to share one collection with other users (eg pictures on a shared directory or on NFS/SMB volume), but with one's own tagging/comments (eg shared directory could be read-only) - provide a quick hack to these network path problems
Fabien, I recommend you look this option from .configure script : --enable-nfs-hack Enable a hack for album libraries on a nfs mount, which causes the database to be saved in $HOMEDIR/.kde/share/apps/digikam/directoryname.db default=disable This is an old feature done by Renchi Raju to solve temporally the NFS problem with SQlite DB... Gilles
I have seen a lot of people suggest the --enable-nfs-hack as a solution, but for me (running Ubuntu) this does not seem to be available: $ digikam --help Usage: digikam [Qt-options] [KDE-options] [options] A Photo-Management Application for KDE Using Kipi library version 0.1.4 Generic options: --help Show help about options --help-qt Show Qt specific options --help-kde Show KDE specific options --help-all Show all options --author Show author information -v, --version Show version information --license Show license information -- End of options Options: --detect-camera Automatically detect and open camera --download-from <path> Open camera dialog at <path> Maybe it's a compile-time option, in which case it doesn't help the average user much (if distros don't include it). I think Fabien's suggested options are EXACTLY WHAT WE NEED. How soon can we have them? Please... :-)
--enable-nfs-hack is a compilation option avaialble on .configure script not like a digiKam command line parameter. Also a new DB interface will be done later 0.9.0 release to be able to work on a remote digiKam Albums collection. Gilles Caulier
Gilles, this is not only about solving problems around network storage, but also to have more flexibility with digikam. See my use cases :) I know a lot of work will be done on Db access after the 0.9.0 release. But, it will take months, maybe 1 year to implement the new db backend, especially if you want to use qt4 with it. I think adding 2 optional cmd-line options could be done in 0.9.1 or 0.9.2. I already tried to change the full path to digikam3.db and it works (one change in 3 files) : digikam/albummanager.cpp: QString dbPath = "/localhome/fabien/Digikam/digikam3.db"; digikam/upgradedb_sqlite2tosqlite3.cpp: QString newDB= "/localhome/fabien/Digikam/digikam3.db"; kioslave/sqlitedb.cpp: QString dbPath = "/localhome/fabien/Digikam/digikam3.db";
Could someone with the proper authority (Gilles?) comment on Fabien's sugestion? To me, a regular user, it seems like exactly what is needed...and it looks like a simple addition to the application. As the months go by without anything (seemingly) being done about the situation, why the big resentment to Fabien's suggestion? Since I am unable to user digiKam, I have now started using GThumb, Picasa and F-Spot. While I don't find any of them to match digiKam's features, Picasa seems to be the closest. So for others with the same digiKam problem as me, I'd recommend taking a look at Picasa. Who knows, I might even get used to it to the point where I give up on pushing for network storage support in digiKam...
I have not yet commented this thread, because network support is planed in the future, especially when we port digiKam to Qt4, to provide a new database backend. Actually we study the better way to do it with Marcel. Gilles
This bug has been there for at least half a year, and I'm guessing a port to Qt4 and/or implementation of a new database backend is at least half a year into the future (not to mention the time it takes to roll down through the distros into the hands of users). I wish the digiKam developers would be willing to implement a quick fix while everyone's waiting for nirvana. That would give users a chance to continue using digiKam, instead of migrating to other solutions.
Marcel, what do you think about Havart comments ? It's fine to touch database stuff now without break something ? Gilles
Just a reference to what I proposed on the devel mailing list... Another bko entry, which is, imho, related to this one : http://bugs.kde.org/show_bug.cgi?id=107871#c6 << I suggest to add 2 command-line options to start digikam. * -f to to specify the full path to digikam3.db, or relative path from the album directory * directory as argument => this would be the album path digikam use Eg: 1) # digikam would behave like now. The 1st time, it will ask for an album path 2) # digikam -f /path/to/digikam3.db would behave like now except it will use the specific path for the database file 3) # digikam /path/to/my/album digikam will use this directory as the album path, but won't override default album path if there's already one 4) # digikam -f /path/to/digikam3.db /path/to/my/album would combine 2) and 3) >> This would not only be a workaround for the nfs/samba locking problem, but also a way to extend digiKam's usage : some people complain that they can only use one library which stores all their pictures. They'd like to have a few libraries. There are also some people who'd like to access pictures on a read-only media (eg DVD). Finally, some people would also like to open a specific directory which contains pictures, like you can do with other tools. All these wishes could be mostly solved by this addon...
The technical problem is that we need to pass the information to the ioslave, in the URL. We could use query items for this, and drop the usage of the "user" field as today.
*** Bug 144724 has been marked as a duplicate of this bug. ***
SVN commit 732444 by cgilles: digiKam from trunk (KDE4) : First very important improvement here depending of the new Database interface/schema dedicaced to 0.10.0 release. A new setting in album configuration page have been added to host the database file used by digiKam in a dedicaced place. Before, the SQlite3 database file (digikam3.db) used by digiKam to store all image informations like Tags, Rating, Comments, Date, etc... been store in the root album path. This solution introduce a big problem to use a root album on a network file system like NFS, because SQLite3 do not like it (look here for more information : http://www.sqlite.org/faq.html#q7) The only issue for this problem is to store the databse file in a separate place... This is want mean than with this commit, digiKam can use a remote root album... There is a screenshot of the new Album config page : http://digikam3rdparty.free.fr/Screenshots/digikamKDE4_13.png The next pending important change to do will to be able to drive more than one root album path with digiKam 0.10.0... CCMAIL: digikam-devel@kde.org CCBUGS: 122516 CCBUGS: 150938 BUG: 129437 BUG: 137694 M +72 -58 digikam/albumsettings.cpp M +3 -0 digikam/albumsettings.h M +1 -1 digikam/digikamapp.cpp M +3 -2 digikam/welcomepageview.cpp M +72 -12 utilities/setup/setupgeneral.cpp M +5 -1 utilities/setup/setupgeneral.h WebSVN link: http://websvn.kde.org/?view=rev&revision=732444
Gilles, thanks a lot for this fix - I am sure it will provide a more widespread use of digikam as it becomes available. Is there a road map for when it will be release (i.e. when 0.10.0 will be released) ? Hopefully it won't be too far into the future...and then I hope it won't take too long for 0.10.0 to trickle down into the distros...
Havard, Release plan is on the web project page : http://www.digikam.org/?q=about/releaseplan Gilles