Restore a backup of your DT database. If you don’t have that, make sure DT is closed, and use the sqlite tools to try and repair your database.
1 Like
Thanks. If DT – or the purge script – doesn’t auto-backup the database, that is going to throw away a massive amount of editing… and I guess I totally deserve it.
Regarding database repair, I’m a bit of a newbie. Is there a link to a walk-through somewhere?
You don’t precise which release you use ?
As I remember, this script has not been updated since a long time and maybe it’s not more usable by now. Not sure but the database as been updated quite a lot these past months.
@Pascal_Obry: what do you think about that ? A script to remove or to update or not related to that ?
Annnnddd that gives me another feature idea…
I recently played with it, but just to make them all more consistent. I haven’t checked sql queries and connections it use so there might be some orphans in db after purge.
2 Likes
I am using 3.0.0 on MacOS.
@paperdigits I just attempted a repair with DB Browser for SQLite, details below.
I ran PRAGMA integrity_check using the walk-through on this link, and it exported into SQL file no problem. When I attempted to import to db file, it would not overwrite onto the old db file, some kind of error was named, so I created a new file name, successfully.
But when I tried to start DT with the new data.db, it crashed on startup again, but with a different error description, namely: Application Specific Information:
abort() called
darktable(1275,0x10e13e5c0) malloc: Incorrect checksum for freed object 0x7ff9acee50a8: probably modified after being freed.
Corrupt value: 0xffffffffffffffff
So far, it looks like I may have stupidly lost just over 2 months of photo editing.
This all started when I decided to shoot raw + JPEG from my camera, imported them all into DT, then realised I really don’t need the JPEG files, so I deleted them from the HDD using the OS file manager (Finder) – only to find DT UI has no simple way to re-synchronise the thumbnails with the actual files on the HDD. The thumbnails of all the deleted JPEG files were ‘stuck’ in Lighttable.
Which led me to the purge script, which took me right outside of my comfort zone, and … ugh.
I can post the full DT crash reports – before and after the repair – if it is any help.
I guess I got used to the comfort of LR making catalog backups at a frequency of my specification, and got out of the habit of thinking “OMG have I backed up everything?” I got lazy.
No, just double checked, the script was not purging two new tables but this cannot be a cause of issues only that some data where left in those tables and not accessible anymore.
1 Like
Good chance that the issue is there indeed !
Oh yes, I knew it straight after I did it. Shows what can happen when you get outside of your comfort zone. For me, that means these scripts, instead of staying inside the UI.
Well not your fault, the scripts should have check that and I have just done that now. If dt is running all scripts modifying the db or preferences will exit with an error message saying:
error: darktable is running, please exit first
When you moved from dt 2.6 to 3.0 an automated backup of your old (2.6) database named library.db-pre-3.0.0 should have been created. Probably you can rescue some of your editing by falling back on this backup.
1 Like
@Pascal_Obry OK, interesting. I didn’t get that error message. Maybe the check fails to run in MacOS?
@pehar yes I have those, they are just over 2 months old.
I just thought of something. Am I over-reacting by thinking I have lost all my editing? I still have all the xmp files for all my photos. Aren’t the edits in them? Does that mean I can just delete data.db and let DT create a new one and still read all my photo edits and tags off the xmp files?
Does losing the db mean I am only losing things like Collections? That is not something I would lose sleep over.
Sorry was not clear, I’ve just added this message this morning after seeing this report 
2 Likes
Yes, edits are in XMP. That’s their reason (a sort of individual database backup). You will not use Collections are they are automatically created from your edits. You should just lose some things elsewhere. Can’t remember what exactly but anyway, it’s just better to loose some settings than 2 months of edit.
You just have to import back your images in darktable.
2 Likes
OK, so I need to rename data.db as a copy, and start DT with no data.db file?
I’m not sure, I never did so. But if you try to do so, please backup all your xmp files of all the images you want to reimport for the case something goes wrong. I would rename data.db and library.db and reimport a folder with a few images for a first test. If this test is successful you can go further steps of reimporting images. Perhaps one of the developers can give more detailed information.
2 Likes
Crash logs always help
I’ll think of adding that to the scripts too in case that may cause DB to grow out of controll with inaccessible data.
Aaaand you’ve beat me to it.
library.db is the more important file, but as @pehar says - backup everything and reimport in small steps.
1 Like
library.db? I attempted repair of data.db but did not attempt library.db. Should I attempt the same repair procedure on that db with DB Browaser for SQLite?
wont hurt. data.db is just styles and stuff. library.db is for all image edits, collections etc. just look at it’s sizes (eg: darktable: periodic database maintenance? - #24 by gadolf) library.db is ~80 MB, when data.db is mere 200kb