You are correct in your analysis re old version of dt. Whilst I cannot remember the exact details, I did try to use the official Fedora version of dt to analyse the DB corruption problem. That failed because dt reported that it could not process the DB because it was "newer".
Obviously this action is ill-advised. Re bash scripting: I've been using Linux for many years, so this is not a problem. I have just edited the sidecar file as you suggested and successfully reloaded it. Thanks for your help, very much appreciated. Cheers, Kevin On Monday, 10 October 2016 3:33:56 PM AEST Tobias Ellinghaus wrote: > Am Montag, 10. Oktober 2016, 10:07:43 CEST schrieb Kevin: > > Hi, > > > > I recently experienced a database corruption - cause unknown. > > > > I restored the database from an appropriate backup and attempted to > > re-import the newer images. This import imported the images but not all > > the > > information in the sidecar files. > > > > After much investigation, I've identified a sidecar file that may be the > > cause of the problem. What I've done is: > > > > 1) Restore the database > > 2) Delete all sidecar files > > 3) Import the RAW images > > 4) Go into Darkroom and inspect the History for the affected image - the > > "default" entries are present (base curve, lens correction & etc) > > 5) Use the Lighttable "Load sidecar file" facility to load the sidecar for > > a single image > > 6) Go into Darkroom and inspect the History for the image - all history > > has > > been deleted and all I have is the original RAW image. > > > > I am currently running the latest software from GIT. > > > > The RAW CR2 image is at https://dl.dropboxusercontent.com/u/9190000/ > > IMG_6227.CR2 > > > > The sidecar file is at https://dl.dropboxusercontent.com/u/9190000/ > > IMG_6227.CR2.xmp > > > > I'll be happy to open a bug report if that is what is required. > > I had a closer look at the XMP file and noticed that you most likely had > that file created by a development build of darktable. Then you tried to > open it using a stable version of dt (or an really old development build) > which broke the XMP file. > There is a way to salvage it though: set "darktable:xmp_version" to "2", > that should be able to be done with sed (after making a backup). Then a > development build should be able to read them again. However, you still > have to go through all files and select the top of the history stack. > Alternatively, if you know how to script, you can set > "darktable:history_end" to the number of history entries in the XMP. You > should be able to get that value with "grep -c darktable:operation <xmp > file>" and then use sed to place it into the file. > > I understand that this will take a little time to learn bash scripting if > you don't know it yet, but it might be a good reminder to never go back to > older darktable versions. > > If you have no idea to do any of the steps I told you to do feel free to > join us in IRC: FreeNode, #darktable, webchat is available here: > https://webchat.freenode.net/?channels=%23darktable > > > Cheers, > > Kevin Gilbert > > Tobias ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
