dt 3.8 windows install comprehensively broken - recovery advice requested

My Windows install of dt 3.8 is now essentially non-functional after running the ‘purge_non_existent_images’ script, under Windows. Could I ask for some advice on how to recover. Here is the background:

My dt 3.8 installation had multiple raw+jpeg pairs, as well as non-paired jpegs. I identified and physically removed most of the paired jpegs using a Windows Powershell script that I was pointed to, designed for this very purpose. In total, this first jpeg deletion phase worked without problem.

This did not solve the issue of removing the unwanted jpeg image information from my dt database. I had expected skulls to be shown after the jpeg image deletion, but they were not. I wanted to avoid the task of manually identifying those images, which would produce a ‘image is not currently available’ message when an attempt was made to open them. I was advised that either running the ‘darktable_generate_cache.exe’ or the ‘purge_non_existing_images’ script would solve the problem.

I ran the generate_cache program, which took almost 3 hours, and partly fixed the problem. On analysing the results, I realised that there were some ‘raw + jpeg’ pairs where the PowerShell script could not work because the raw and the jpeg images had different filenames (!) - (the toxic result of having to recover from an infamous screw-up in Nikon Image Transfer software from about 12 years ago). These latter jpegs were removed by hand after a visual comparison of the raw and jpeg. In order then to avoid another 3 hours period to regenerate the cache (or so I thought), I chose to run the ‘purge’ script to remove the remaining skulls. The documentation for doing this is relevant to a Linux install only, but there is, on this forum from Feb '20, an article, by GuK, on how to set-up and run this bash script under windows. I followed this article, and finally, after getting sqlite3 installed, running the purge script without and then with the --purge option.

At this point all images, of all types, from all directories within my Pictures directory, were removed from my dt database and library (but not physically removed from the drive). I was left with a completely empty dt install.

My first recovery action was to replace the data.db and library.db files with copies of those files from backup. This did not repopulate my dt install, for reasons I don’t understand - those backups were made before I ran the ‘purge’ script.

My next recovery action was to replace the data.db and library.db files from the latest snapshot version, which were about 6 hours old. This gave me a dt installation with all my image accessible, but with skulls shown for all deleted jpegs, whether from fully paired images. or mages which had been deleted by hand. However, the behaviour of dt was now strange:

  • I was unable to select any single image or all images
  • invoking the ‘collapse grouped mages’ button caused an individual skull to disappear, but not be deleted - pressing the button again caused the skull to reappear
  • the full path information under ‘image information’ was totally misleading: it showed a path to an image which was not visible in the central panel of the lighttable. In fact, positioning the cursor on any grey part of this central panel - any part not occupied by an image - showed this same full path information in the image information area.
  • clicking on the ‘remove’ button in ‘selected image(s)’ panel would ask for confirmation and apparently result in the removal of an image, but nothing actually happened.

I decided to run the ‘generate-cache’ program again, but it produced 3 errors for every image as follows: “open-square-bracket image_cache_write_release close-square-bracket sqlite error 8”. Bearing in mind there were now 4 lines of output per image, each taking about 1.5 seconds to show, it was clear that this process would take about 20 hours to complete, so I stopped it.

At that point, I decided to seek help.

I don’t know if it is relevant, but as part of following the article from Feb '20 on how to set up to run the ‘purge’ bash script under windows, I installed the following sqlite3 files in:
c:\Program Files\Git\mingw64\bin

  • sqldiff.exe
  • sqlite3.exe (version 3.31.1.0)
  • sqlite3-analyzer.exe
  • sqlite3.def
  • sqlite3.dll (version 3.38.2.0)

Any advice?

You have done a lot of bashing around with your files. I am not sure why your backups don’t work?? THat seems curious…

In any case…and still keeping all your backups if you have your xmp files maybe just reimport everything over night…

One last thing you could try is to delete your cache files maybe they are corrupted.

Thanks for taking the time to advise me. I’m confident that I have all the image data (image plus .xmp (ex-Lightroom) plus raw.xmp (ex-dt)) is well backed up and protected, multiple times. However, there are some things that I am ignorant of and hence imagining the worst case result:

  • where/how is my tag and added meta-data data (hard won, many hours of work) kept and how is it protected?

  • is existing ‘raw.xmp’ ‘jpg.xmp’ data overwritten when re-importing the image file?

  • if the re-import fails, have I lost my tag and meta-data?

  • are the cache files for Windows those located in c:/Users//AppData/Local/Microsoft/Windows/InetCache/darktable ?

  • Are both the Cached_Kernels* and mipmaps* folders included within the term ‘cache files’? the manual does not explicitly state,

  • the contents of the Cached_Kernels folder appear to be dt module related, not image thumbnail related - they don’t look like thumbnail caches at all.

  • if a clean re-install of dt proves to be required, have I lost my tag and meta data information ?

  • to what extent can I copy dt configuration data files from my Linux install to my Windows install?

The configuration and operation files of darktable.pdf (183.9 KB)

The thumbs are in the mipmaps…

I cant sat with certainty that all info is in the xmp but think most is …you can wait for an expert opinion…

If this were me I would run DT using a new config directory and try to import a folder or two …if all looks good then you could import everything.

Then just use this set of files or copy it back to the main config directory…

This is almost like starting with a new install and shouldn’t mess with anything in your original install …you could also specify a new cache directory from the command line to see if that helps…so it would be quick and easy to try a new config and cache directory…