Hi,
For some years, I have had my digikam collection on a portable USB drive, which I mounted on /photodisk. This portable USB drive is now too small to store my photo collection, so I have moved the photos onto a NAS. The files are now served via NFS. So on my photo editing machine, I mount photos on /net/photo instead of /photodisk. I also got a new computer for photo editing on which I need to set this all up. I saved the digikamrc as well as a dump of digikam4.db and thumbnails-digikam4.db. So, now my question is, how do I get this all up and running again with the collection in the new location and digikam on a new computer? I see that the SQL dump of digikam4.db has this line: INSERT INTO "AlbumRoots" VALUES(8,'photos',0,1,'volumeid:?path=%2Fphotodisk%2Ftdn-photos%2Fphotos','/'); Should I just change this to: INSERT INTO "AlbumRoots" VALUES(8,'photos',0,1,'volumeid:?path=%2Fnet%2Fphoto%2Fphotos','/'); And then restore the digikam db? Maybe I am just looking the wrong places, but I have a hard time finding documentation on this. I figure this should actually be a very easy task, as it basically is the same that is needed if a user needs to recover from backup or similar. Med venlig hilsen/Kind regards Thomas _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Hi Thomas, On Sun, 24 Jun 2012, Thomas wrote: > So, now my question is, how do I get this all up and running again > with the collection in the new location and digikam on a new computer? > > I see that the SQL dump of digikam4.db has this line: > INSERT INTO "AlbumRoots" > VALUES(8,'photos',0,1,'volumeid:?path=%2Fphotodisk%2Ftdn-photos%2Fphotos','/'); > > Should I just change this to: > INSERT INTO "AlbumRoots" > VALUES(8,'photos',0,1,'volumeid:?path=%2Fnet%2Fphoto%2Fphotos','/'); > And then restore the digikam db? when replicating (rsync) DK database between two computers, a desktop and a laptop, and yes, I have to change the path of the collection base directory. A simple command line SQL command can do "UPDATE TABLE ... " etc. One more thing you should check is the location of your DB file, the digikam4.db, because it's stored into the DK runtime configuration file, $HOME/.kde4/share/config/digikamrc If your DB file is stored at the root of your collection, you'll also have to change the "Database Name=" parameter from, e.g. /photodisk/photos to /net/photo/photos, so that DK can find your new DB upon next startup. And if your DB file is on your local computer, not on a USB drive or network drive, of course nothing to change in rc configuration. Regards, Jean-François _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On 06/25/12 06:10, Jean-François Rabasse wrote:
> > Hi Thomas, > > On Sun, 24 Jun 2012, Thomas wrote: > >> So, now my question is, how do I get this all up and running again >> with the collection in the new location and digikam on a new computer? >> >> I see that the SQL dump of digikam4.db has this line: >> INSERT INTO "AlbumRoots" >> VALUES(8,'photos',0,1,'volumeid:?path=%2Fphotodisk%2Ftdn-photos%2Fphotos','/'); >> >> >> Should I just change this to: >> INSERT INTO "AlbumRoots" >> VALUES(8,'photos',0,1,'volumeid:?path=%2Fnet%2Fphoto%2Fphotos','/'); >> And then restore the digikam db? > > Seems good. That kind of tweak works for me, I have similar problems > when replicating (rsync) DK database between two computers, a desktop > and a laptop, and yes, I have to change the path of the collection > base directory. > A simple command line SQL command can do "UPDATE TABLE ... " etc. > > One more thing you should check is the location of your DB file, the > digikam4.db, because it's stored into the DK runtime configuration > file, $HOME/.kde4/share/config/digikamrc > If your DB file is stored at the root of your collection, you'll > also have to change the "Database Name=" parameter from, e.g. > /photodisk/photos to /net/photo/photos, so that DK can find your new DB > upon next startup. > > And if your DB file is on your local computer, not on a USB drive or > network drive, of course nothing to change in rc configuration. > > > > Regards, > Jean-François I'm not sure about the latest version of digiKam, but I think if you want the database on NAS you need to use mysql. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
2012/6/26 Jim Householder <[hidden email]>
Why is that? I see that I get extremely many errors such as these: digikam(12860)/digikam (core) Digikam::DatabaseCoreBackendPrivate::checkRetrySQLiteLockError: Database is locked. Waited 1240 digikam(12860)/digikam (core) Digikam::DatabaseCoreBackendPrivate::checkRetrySQLiteLockError: Database is locked. Waited 1250 digikam(12860)/digikam (core) Digikam::DatabaseCoreBackendPrivate::checkRetrySQLiteLockError: Database is locked. Waited 1260 digikam(12860)/digikam (core) Digikam::DatabaseCoreBackendPrivate::checkRetrySQLiteLockError: Database is locked. Waited 1270 digikam(12860)/digikam (core) Digikam::DatabaseCoreBackendPrivate::checkRetrySQLiteLockError: Database is locked. Waited 1280 However, the *database* (digikam4.db) is *not* located on network filesystem. Only the photos are. I do not understand why this should be a problem. Regards, Thomas _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Jean-François Rabasse
2012/6/25 Jean-François Rabasse <[hidden email]>
I have tried changing the collection path in my SQL dump of the digikam4.db, then restored the db. I have then copied the old digikamrc into ~/Pictures/digikam4.db Then I started digikam.. I see that is has my albums and tags. Howeverr, when I click an album in My Albums, no photos are shown. Even though digikam says it has 1145 photos (or similar) in the paranthesis after the album name. If I go to My Tags and click a tag that should have photos in it, no phottos are shown. digikam is now also horribly slow. Even though my new computer is immensely faster than the old one. digikam prints *lots* of these errors: digikam(14521)/digikam (core) Digikam::DatabaseCoreBackendPrivate::checkRetrySQLiteLockError: Database is locked. Waited 5600 digikam(14521)/digikam (core) Digikam::DatabaseCoreBackendPrivate::checkRetrySQLiteLockError: Database is locked. Waited 5610 Please note that only photos are on NFS. The database is on local filesystem. Med venlig hilsen/Kind regards Thomas _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
More info.
Digikam produces lots of lines like these: digikam(14521)/digikam (core) Digikam::DImg::load: "/net/photo/photos/2008/2008-02-Val-dIsere/raw/p2013103.orf" : RAW file identified digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : No image data to encode Exif.OlympusCs.PreviewImageStart. digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.Olympus2.ThumbnailImage not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusCs.PreviewImageLength not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusCs.PreviewImageStart not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusCs.PreviewImageValid not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.Photo.MakerNote not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusIp.0x1103 not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusIp.0x1104 not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2ExceptionError: Cannot find Xmp key 'Xmp.MP.RegionInfo/MPRI:Regions[1]/MPReg:PersonDisplayName' into image using Exiv2 (Error # 35 : No namespace info available for XMP prefix `MP' digikam(14521)/digikam (core) Digikam::DImg::load: "/net/photo/photos/2008/2008-02-Val-dIsere/raw/p2013104.orf" : RAW file identified digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : No image data to encode Exif.OlympusCs.PreviewImageStart. digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.Olympus2.ThumbnailImage not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusCs.PreviewImageLength not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusCs.PreviewImageStart not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusCs.PreviewImageValid not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.Photo.MakerNote not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusIp.0x1103 not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusIp.0x1104 not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2ExceptionError: Cannot find Xmp key 'Xmp.MP.RegionInfo/MPRI:Regions[1]/MPReg:PersonDisplayName' into image using Exiv2 (Error # 35 : No namespace info available for XMP prefix `MP' digikam(14521)/digikam (core) Digikam::DImg::load: "/net/photo/photos/2008/2008-02-Val-dIsere/raw/p2013105.orf" : RAW file identified digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : No image data to encode Exif.OlympusCs.PreviewImageStart. digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.Olympus2.ThumbnailImage not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusCs.PreviewImageLength not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusCs.PreviewImageStart not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusCs.PreviewImageValid not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.Photo.MakerNote not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusIp.0x1103 not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusIp.0x1104 not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2ExceptionError: Cannot find Xmp key 'Xmp.MP.RegionInfo/MPRI:Regions[1]/MPReg:PersonDisplayName' into image using Exiv2 (Error # 35 : No namespace info available for XMP prefix `MP' digikam(14521)/digikam (core) Digikam::DImg::load: "/net/photo/photos/2008/2008-02-Val-dIsere/raw/p2013106.orf" : RAW file identified digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : No image data to encode Exif.OlympusCs.PreviewImageStart. digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.Olympus2.ThumbnailImage not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusCs.PreviewImageLength not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusCs.PreviewImageStart not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusCs.PreviewImageValid not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.Photo.MakerNote not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusIp.0x1103 not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusIp.0x1104 not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2ExceptionError: Cannot find Xmp key 'Xmp.MP.RegionInfo/MPRI:Regions[1]/MPReg:PersonDisplayName' into image using Exiv2 (Error # 35 : No namespace info available for XMP prefix `MP' digikam(14521)/digikam (core) Digikam::DImg::load: "/net/photo/photos/2008/2008-02-Val-dIsere/raw/p2013107.orf" : RAW file identified digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : No image data to encode Exif.OlympusCs.PreviewImageStart. digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.Olympus2.ThumbnailImage not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusCs.PreviewImageLength not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusCs.PreviewImageStart not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusCs.PreviewImageValid not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.Photo.MakerNote not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusIp.0x1103 not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2MessageHandler: Exiv2 ( 2 ) : Exif tag Exif.OlympusIp.0x1104 not encoded digikam(14521)/KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::printExiv2ExceptionError: Cannot find Xmp key 'Xmp.MP.RegionInfo/MPRI:Regions[1]/MPReg:PersonDisplayName' into image using Exiv2 (Error # 35 : No namespace info available for XMP prefix `MP' ^C It seems to me that digikam has begun scanning my entire collection, but that should not be necessary, should it? I mean, the photos has not changed. So from digikam's perspective it should just be another regular day as usual. Digikam should be unaware that the path has been changed, since I have changed this in the db before starting digikam. What to do? Of course, I have backup of both db and digikamrc from before. Med venlig hilsen/Kind regards Thomas 2012/6/26 Thomas <[hidden email]>
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Jim Householder
2012/6/26 Jim Householder <[hidden email]>
1: If I use MySQL instead, does that mean I can put the DB on the NAS and then access it from multiple clients (i.e. multple computers running digikam but using the same db?) 2: I can install MySQL server on the NAS, no problem. However, I am not sure how I convert my existing SQLite db into MySQL? Is there a way to import it? And does that require a working digikam set up?
3: I normally use PostgreSQL. Is it possible to use that instead of MySQL?
Med venlig hilsen/Kind regards Thomas _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Jean-François Rabasse
2012/6/25 Jean-François Rabasse <[hidden email]>
> On Sun, 24 Jun 2012, Thomas wrote: >> So, now my question is, how do I get this all up and running again >> with the collection in the new location and digikam on a new computer? >> >> I see that the SQL dump of digikam4.db has this line: >> INSERT INTO "AlbumRoots" >> VALUES(8,'photos',0,1,'volumeid:?path=%2Fphotodisk%2Ftdn-photos%2Fphotos','/'); >> >> Should I just change this to: >> INSERT INTO "AlbumRoots" >> VALUES(8,'photos',0,1,'volumeid:?path=%2Fnet%2Fphoto%2Fphotos','/'); >> And then restore the digikam db? > > > Seems good. That kind of tweak works for me, I have similar problems > when replicating (rsync) DK database between two computers, a desktop > and a laptop, and yes, I have to change the path of the collection > base directory. > A simple command line SQL command can do "UPDATE TABLE ... " etc. > > One more thing you should check is the location of your DB file, the > digikam4.db, because it's stored into the DK runtime configuration > file, $HOME/.kde4/share/config/digikamrc > If your DB file is stored at the root of your collection, you'll > also have to change the "Database Name=" parameter from, e.g. > /photodisk/photos to /net/photo/photos, so that DK can find your new DB upon next startup. > > And if your DB file is on your local computer, not on a USB drive or > network drive, of course nothing to change in rc configuration. My DB is on my local computer in ~/Pictures/digikam4.db I have now tried from a local file system instead of NFS/NAS. I still get this error from digikam: digikam(28701)/digikam (core) Digikam::DatabaseCoreBackendPrivate::checkRetrySQLiteLockError: Detected locked database file. There is an active transaction. Waited but giving up now. Please, is there any way I can just recover all my digikam tags from the DB, so that I can import them into a new digikam DB? This stuff needs to be robust. It takes huge amounts of work to tag so many photos. We cannot let users lose important data like this. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Hello Thomas, On Sat, 28 Jul 2012, Thomas wrote: > My DB is on my local computer in ~/Pictures/digikam4.db > > I have now tried from a local file system instead of NFS/NAS. > > I still get this error from digikam: digikam(28701)/digikam (core) > Digikam::DatabaseCoreBackendPrivate::checkRetrySQLiteLockError: > Detected locked database file. There is an active transaction. > Waited but giving up now. As for me I've never seen that kind of message. Usually databases locking may occur upon a system crash or a DB file backup while an application has a current pending transaction. As far as I know, sqlite3 uses standard files locks to implement access (the flock() system call, and flock() doesn't work very well with NFS mounted volumes. This, under Linux; it works better under Solaris but very few users use Solaris86). Maybe there's a way to drop locks via some sqlite3 commands on the file. Perhaps you should have a look at http://www.sqlite.org/lockingv3.html Something else that may work (at least is worth trying because it's really simple) is to dump your database : sqlite3 digikam4.db '.dump' > db.dump remove your DB file (backup) : mv digikam4.db digikam4.db.bak rebuild an all new DB from the previous dump : sqlite3 digikam4.db < db.dump Probably internal DB state, locks et al., aren't exported during a SQL dump. Shouldn't, but this has to be checked. > Please, is there any way I can just recover all my digikam tags from > the DB, so that I can import them into a new digikam DB? > > This stuff needs to be robust. It takes huge amounts of work to tag > so many photos. We cannot let users lose important data like this. I fully agree with the fact that tagging, documenting, geolocating images is a bunch of work. More, I think this work is expected to have a VERY long lifetime. (As for myself, I consider that lifetime should be « forever », same as the images themselves.) Given that, my *personal opinion* is that a database is of no use for that. Database schemes evolve with applications versions and DB engines versions and there's no chance that your SQLite3 Digikam DB of today could still be valid in 20 years from now. And what about the case you change your images management software some day ! For me, databases are only « work data », to allow an application doing fast search and filtering tasks via SQL selection requests. It's not an archival system at all and it should be expected to be rebuilt from scratch, provided the informations are saved somewhere under a more robust format. And (always my personal opinion) that's why I do write metadata into the images files, EXIF/GPSsubIFD for geolocation infos, and XMP for other metadata. And I want to believe I'll still be able to read/extract that, even in 10 or 20 years. I don't trust xmp sidecar files, not standard at all between applications even today. My bet is that at any time, any metadata reading program could allow extracting the informations to reinject into some other system, be it in 2015, or 2025, or 2035 ... But this is only a personal point of view, probably this is an interesting discussion topic : what reliable solutions to answer the good initial question « What about my metadata in 20 years ? » :-) Regards, Jean-François _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On 28.07.2012 17:27, Jean-François Rabasse wrote:
> On Sat, 28 Jul 2012, Thomas wrote: >> Please, is there any way I can just recover all my digikam >> tags from >> the DB, so that I can import them into a new digikam DB? >> >> This stuff needs to be robust. It takes huge amounts of >> work to tag >> so many photos. We cannot let users lose important data >> like this. > > I fully agree with the fact that tagging, documenting, > geolocating > images is a bunch of work. More, I think this work is > expected to have > a VERY long lifetime. (As for myself, I consider that > lifetime should > be « forever », same as the images themselves.) > > Given that, my *personal opinion* is that a database is of > no use for > that. Database schemes evolve with applications versions and DB > engines versions and there's no chance that your SQLite3 > Digikam DB of > today could still be valid in 20 years from now. And what > about the > case you change your images management software some day ! > > For me, databases are only « work data », to allow an > application > doing fast search and filtering tasks via SQL selection > requests. > It's not an archival system at all and it should be expected > to be > rebuilt from scratch, provided the informations are saved > somewhere > under a more robust format. > > And (always my personal opinion) that's why I do write > metadata into > the images files, EXIF/GPSsubIFD for geolocation infos, and > XMP for > other metadata. And I want to believe I'll still be able to > read/extract that, even in 10 or 20 years. I don't trust xmp > sidecar > files, not standard at all between applications even today. > > My bet is that at any time, any metadata reading program > could allow > extracting the informations to reinject into some other system, > be it in 2015, or 2025, or 2035 ... > But this is only a personal point of view, probably this is an > interesting discussion topic : what reliable solutions to > answer the > good initial question « What about my metadata in 20 years ? > » :-) > > Regards, > Jean-François Those are exactly my thoughts about storing metadata! I couldn't have expressed it in better words! ;) No real contribution to this thread, but you are not alone Jean-François. ;) Regards, Peter _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
> On 28.07.2012 17:27, Jean-François Rabasse wrote:
>> good initial question « What about my metadata in 20 years ? the real question, now that personal computer are 30 years old is where will *I* be in 20 years. and if I'm no more in this world, where will all my data go? but of course, Digikam can be of little help there :-)) jdd (and I agreee with all what you said) -- http://www.dodin.org http://jddtube.dodin.org/20120616-52-highway_v1115 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
2012/7/28 jdd <[hidden email]>:
>> On 28.07.2012 17:27, Jean-François Rabasse wrote: >>> >>> good initial question « What about my metadata in 20 years ? > > > > the real question, now that personal computer are 30 years old is where will > *I* be in 20 years. > > and if I'm no more in this world, where will all my data go? > > but of course, Digikam can be of little help there :-)) Now you are talking about existential questions. That's another direction. Me myself don't believe in a life after death, rather a life before death. So for me what happens with my images after my own death is irrelevant. It might not be irrelevant for my relatives though... /Anders > > jdd > (and I agreee with all what you said) > > > -- > http://www.dodin.org > http://jddtube.dodin.org/20120616-52-highway_v1115 > > > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Le 29/07/2012 09:29, Anders Stedtlund a écrit :
> Now you are talking about existential questions. That's another > direction. Me myself don't believe in a life after death, rather a > life before death. So for me what happens with my images after my own > death is irrelevant. It might not be irrelevant for my relatives > though... I don't want to begin philosophic discussion, but technical one. I'm 66 and nobody in my neiborhood seems to care about managing the photo collection I have (they like to look at it though), so I wonder what will be the safest way to make them easily available if ever I can't manage then anymore (even being alive). for now hard drive and chronological sorting seems the best (and metadata storage) jdd -- http://www.dodin.org http://jddtube.dodin.org/20120616-52-highway_v1115 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
2012/7/29 jdd <[hidden email]>:
> Le 29/07/2012 09:29, Anders Stedtlund a écrit : > > >> Now you are talking about existential questions. That's another >> direction. Me myself don't believe in a life after death, rather a >> life before death. So for me what happens with my images after my own >> death is irrelevant. It might not be irrelevant for my relatives >> though... > > > > I don't want to begin philosophic discussion, but technical one. > > I'm 66 and nobody in my neiborhood seems to care about managing the photo > collection I have (they like to look at it though), so I wonder what will be > the safest way to make them easily available if ever I can't manage then > anymore (even being alive). > > for now hard drive and chronological sorting seems the best (and metadata > storage) Yeah, that was a detour.. I have all my images sorted in folders by date. Then have metadata in db and xmp-sidecar files. One way is to have the metadata in the image files but as that's experimental for raw it seems not be an option. I'm also against to alter the image files in general so... xmp-sidecar is the prefered way for me. Unfortunately there is no standard way there. On the other hand there will probably not be an abrupt discontinuation of the used software so one might migrate over time. /Anders > > jdd > > > > -- > http://www.dodin.org > http://jddtube.dodin.org/20120616-52-highway_v1115 > > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Jean-François Rabasse
2012/7/28 Jean-François Rabasse <[hidden email]>
This seemed to work. Thanks. Med venlig hilsen/Kind regards Thomas _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Free forum by Nabble | Edit this page |