Unclearable presence of skulls (missing images)
The skulls that denote missing images never go away.
I am guessing that these derive from darktable remembering in its sqlite-based index that an image of a certain name once existed in a certain directory.
The only workaround I have found is moving the entire directory to a new name, which invalidates previous darktable caches.
There should be some other option here, such as:
(1) automatically invalidating the entry instead of showing a skull
(2) providing a button that reloads the current directory's entries from disk, clearing skulls by and invalidating previously cached ideas about which files have been present in the directory in the past
Personally I am keen on option #1 as I think the additional complexity of a skull and the type of approach to file management/workflow that it engenders is essentially needless and creates a barrier for inuitive use by new users. In short, it adds little functionality in many cases and confuses people.
The bug is made more serious by the fact that at least part of the development team seems keen on avoiding any file management within darktable, which then means that people do this manually, which naturally leads to skull growth conditions :)
#2 Updated by Walter de la Internet over 4 years ago
Well, sure. Manual processing might be option, but it's annoying. Maybe I didn't notice this 'delete' working on my (Macbook) keyboard as delete is mapped to backspace.
I still think there is a fundamental disconnection between index and reality, the management of which needs to be considered.
For example in one folder right now I am not seeing skulls but rather the assumedly related problem of loads of icons for images no longer present that, when clicked to get to darkroom view, trigger "image <imagename> is currently unavailable".
I think I once determined that this may be related to opening a folder without write permissions resulting in metadata being stored someplace else (~/.darktable or somewhere else dotfilesque / similar?)