/home/user/.config/tracker/tracker-miner-fs.cfg IndexRecursiveDirectories, IndexSingleDirectories, CrawlingInterval eh, my reasons for disliking it are complicated. ill try and list some, but it comes down to unpredictability and lack of user control. 1) i move my files around a lot, and the tracker slows my phone to a crawl when i do large updates. for instance, every night i run a machine that backs up all the photos in MyDocs to my laptop, indexes them into my storage system, runs a conversion to shrink them to the n9's resolution, and syncs my entire low-res library back to the n9 {currently about 2GiB}. i manually reorganize my high-res images routinely, and the nightly script deals with re-converting to low-res. i do the same exact thing with my FLAC music library, maintaining an ogg "mirror" of my music library with a quality=6 conversion on my laptop, which then gets synced to my phone nightly. i manually update my FLACs, adding music, changing tags, then rerun my conversion. 2) i absolutely despise the harmattan gallery, music-suite, and video-suite apps. i use meeseepics, my own oddball music app called klomp, and mplayer. {meeseepics is flawed, but sufficient} 3) tracker is wasteful if you dont use it, and its not optimized to handle what i do. i dont use it for music at all, and it spends an inordinate amount of time indexing my large library. i would be happier if it only [re]indexed things as they were ACCESSED, and not as they are modified. when nothing has been modified, this check is extremely cheap. 4) i dislike complex, non-human-readable state. i would prefer favorites to be stored in a way that is transparent to the user and easy to preserve across machines. 5) i like predictability in behaviours. i would like tracker to act merely as a cache of the filesystem; asking it for a list of files would then ensure that the index of each of those files is up-to-date before returning it. the key is that the behaviour is the same before and after a tracker crawl. then, one could update parts of the cache at as desired and not change the behaviours, but only improve performance. 6) the tracker stores the call log and sms message log. it also stores huge blocks of text for localization and stuff. its over-used, and many features depend on it. the interfaces that access it are often buggy. {note how many sms bugs stem from it, and are fixable only by removing the tracker db} i dislike relying on the tracker to keep track of my media when all those other things break it and otherwise complicate things. not to say that you shouldnt use tracker, but there are many tools for reading exif metadata. as for deletion detection, you can just check that the file exists when initiating swipe to it.
how does it persist the index? does it store a list of used indices for each date that a picture was taken? can this method break if one changes the date to a previously used date, e.g.: by changing timezones?
probably the solution i would like best would be to have camera+ attempt to ensure what it needs from the tracker is an accurate reflection of the filesystem. as a workaround, i could probably figure out how to index precisely what i want indexed when i want it indexed so that camera+ works as if it was actually looking at my pictures, instead of what the tracker thinks my pictures are. i tried indexing DCIM manually and no changes were reflected in camera+. not sure why; i should probably look into it