GNOME Bugzilla – Bug 719306
Give a mime-type priority to miners
Last modified: 2013-12-03 20:59:09 UTC
It should be possible to tell miners to index some mime types first. For example when user opens a music app and tracker is still crawling for new files, we should tell tracker to index audio files first and only come back to index other files later when all audio files are extracted.
(In reply to comment #0) > It should be possible to tell miners to index some mime types first. For > example when user opens a music app and tracker is still crawling for new > files, we should tell tracker to index audio files first and only come back to > index other files later when all audio files are extracted. Interesting idea. I believe you can do this with the current DBus API asking tracker to index particular files, but it's not by MIME type. There is an API to reindex all MIME types, but that's not the same. How would this work if there were other applications contending for indexing time? First come first serve basis?
(In reply to comment #1) > (In reply to comment #0) > How would this work if there were other applications contending for indexing > time? First come first serve basis? I would say, the app having focus has priority. Or it could index a set of mime types which is the union of what each running is asking. For example: 1) App A calls Tracker1.Miners.IndexFirst("audio/*"). Tracker keeps a map {A: "audio/*"} and start ignoring all files that does not match that when crawling. 2) App B calls Tracker1.Miners.IndexFirst("video/*"). Tracker keeps a map {A:"audio/*", B:"video/*"} and now ignore all files that does not match video or audio. 3) App A leaves (tracker knows it by watching bus names). Tracker removes A from the map and now it ignore all bug "video/*". I reckon implementation details can get tricky to implement. For example how does tracker "come back" to files it ignored because of the "audio/*" filter when the filter is removed, or when it's done indexing all audio files?
I think this bug has lots in common with bug #715194, so I opened bug #719802 to handle both cases. *** This bug has been marked as a duplicate of bug 719802 ***