I don’t copy photos to a harddrive, I keep them on the original SD cards (I know, I know, but I’ve bought M-discs to back them up to).
I fully understand Darktable showing skulls for photos for which the SD card isn’t present (although it actually caches thumbnails better on my Linux laptop), but now I put an old card in and was looking for a specific image and couldn’t find it.
So I began browsing the SD card via Windows Explorer instead and found the photo.
Went back to Darktable and double clicked the skull I knew was supposed to be the photo… and it loaded! And once back to Lighttable the thumbnail showed up.
First, why does it do this? Second, how can I force a refresh of skull icons to proper thumbnails?
Thanks, this seems to have worked! I ran it once for very SD card I inserted.
Only issue now is I have to manually clean out the skull icons which are actually missing, probably for when I edited some photos on my laptop, and other photos on my desktop.
I think you are creating your own problem by storing the photos on the SD cards.
You may want to open a feature request to support your use case (the path to the photos does not change, so your point is at least understandable). I’d advise against wording it as ‘show the bloody cached thumbnail’, though.
You probably don’t have all those SD cards connected permanently to your computer. So how is darktable to know files on a visible SD card corresponds to the thumbnails in the cache?
Unless you take great care that a given SD card is always mounted on the same path, just plugging in an SD card is not guaranteed to do that. That’s not something darktable can handle either, it’s handled by the OS (luckily, given the variety of disk technologies and filesystems out there).
(and no, filenames are not guaranteed to be unique either… fingerprinting the files may work, but would be very slow).
If you want to use SD cards as permanent storage, that’s your choice. But you’ll have to accept the consequences…
I don’t know… regardless I just see problems, not solutions…
I have a Windows desktop and a Linux laptop and Darktable is cross platforms but apparently with no way to share a library of photos that’s on the local network (if I would to put all SD card contents on my media PC which both of those can see).
Unless I misunderstood that thread I linked, because one computer is Windows and the other is Linux, that will not work since the paths to (the same) network location is different.
I suspect the only thing which could work would be if the library.db was allowed to be placed at the root of the network shared Pictures folder and use relative paths and both Darktable installs could use the same file (since it has a lock system already).
This issue is solvable since you can apparently tell darktable which DB to open with the - - library Option. See here. However you probably can’t Mix Windows and Linux in this case because apparently the DB uses absolute filepaths.
So today on my laptop I accidentally forgot to connect to the network drive before I opened Darktable… so again, skulls every-bloody-where!
And they don’t seem to go away either now that I connected to the drive and restarted Darktable. When I scroll through images, those without thumbnails get generated, but the skulls only go away if I double click on them first.
For a single user it could be done relatively quickly given that exif data is available. Without it it would be very slow indeed.
–
This seems like a darktable problem and I think you should open a feature request on github.
It clearly checks the disk to see if the files exist before nuking the thumbnail and most likely marking the file as moved, but I don’t see why it shouldn’t re-check them once a user opens the directory again. There’s nothing to gain by not doing so, given that it already scans files which are not marked as moved.
It’s definitely a curious design decision and I’m curious to know the reason behind it having been implemented this way.