Tag Archives for Tracker

Every 6 months or so we produce a new stable release and for Tracker 1.2 we had some new exciting work being introduced. For those that don’t know of Tracker, it is a semantic data storage and search engine for desktop and mobile devices. Tracker is a central repository of user information, that provides two big benefits for the user; shared data between applications and information which is relational to other information (for example: mixing contacts with files, locations, activities and etc.).

Providing your own data

Earlier in the year a client came Lanedo and to the community asking for help on integrating Tracker into their embedded platforms. What did they want? Well, they wanted to take full advantage of the Tracker project’s feature set but they also wanted to be able to use it on a bigger scale, not just for local files or content on removable USB keys. They wanted to be able to seamlessly query across all devices on a LAN and cloud content that was plugged into Tracker. This is not too dissimilar to the gnome-online-miners project which has similar goals.

The problem

Before Tracker 1.2.0, files and folders came by way of a GFile and GFileInfo which were found using the GFileEnumerator API that GLib offers. Underneath all of this the GFile* relates to GLocalFile* classes which do the system calls (like lstat()) to crawl the file system.

Why do we need this? Well, on top of TrackerCrawler (which calls the GLib API), is TrackerFileNotifier and TrackerFileSystem, these essentially report content up the stack (and ignore other content depending on rules). The rules come from a TrackerIndexingTree class which knows what to black list and what to white list. On top of all of this is TrackerMinerFS, which (now is inaccurately named) handles queues and processing of ALL content. For example, DELETED event queues are handled before CREATED event queues. It also gives status updates, handles INSERT retries when the system is busy and so on).

To make sure that we take advantage of existing technology and process information correctly, we have to plugin at the level of the TrackerCrawler class.

The solution

Essentially we have a simple interface for handling open and close cases for iterating a container (or directory) called TrackerDataProvider interface (and TrackerFileDataProvider implementation for the default or existing local file system case).

That is followed up with an enumerator interface for enumerating that container (or directory). That is called TrackerEnumerator and of course there is a TrackerFileEnumerator class to implement the previous functionality that existed.

So why not just implement our own GFile backend and make use of existing interfaces in GLib? Actually, I did look into this but the work involved seemed much larger and I was conscious of breaking existing use cases of GFile in other classes in libtracker-miner.

How do I use it?

So now it’s possible to provide your own data provider implementation for a cloud based solution to feed Tracker. But what are the minimum requirements? Well, Tracker requires a few things to function, those include providing a real GFile and GFileInfo with an adequate name, and mtime. The libtracker-miner framework requires the mtime for checking if there have been updates compared to the database. The TrackerDataProvider based implementation is given as an argument to the TrackerMiner object creation and called by the TrackerCrawler class when indexing starts. The locations that will be indexed by the TrackerDataProvider are given to the TrackerIndexingTree and you can use the TRACKER_DIRECTORY_FLAG_NO_STAT for non-local content.

Crash aware Extractor

In Tracker 1.0.0, the Extractor (the ‘tracker-extract’ process) used to extract metadata from files was upgraded to be passive. Passive meaning, the Extractor was only extracting content from files already added to the database. Before that, content was concatenated from the Extractor to the file system miner and inserted into the database collectively.

Sadly with 1.0.0, any files that caused crashes or serious system harm resulting in the termination of ‘tracker-extract’ were subsequently retried on each restart of the Extractor. In 1.2.0 these failures are noted and files are not retried.

New extractors?

Thanks to work from Bastien Hadess, there have been a number of extractors added for electronic book and comic books. If your format isn’t supported yet, let us know!

Updated Preferences Dialog

Often we get questions like:

Can Tracker index numbers?

How can I disable indexing file content?

To address these, the preferences dialog has been updated to provide another tab called “Control” which allows users to change options that have existed previously but not been presented in a user interface.

In addition to this, changing an option that requires a reindex or restart of Tracker will prompt the user upon clicking Apply.

What else changed?

Of course there were many other fixes and improvements as well as the things mentioned here. To see a full list of those, see them as mentioned in the announcement.

Looking for professional services?

If you or someone you know is looking to make use of Open Source technology and wants professional services to assist in that, get in touch with us at Lanedo to see how we can help!

Over the past month or two, I’ve spent time working on various feature branches for Tracker. This coming after a 1.2 stable release and a new feature set which was added in 1.2.

So a lot has been going on with Tracker internally. I’ve been relatively quiet on my blog of late and I thought it would be a good idea to run a series of blogs relating to what is going on within the project.

Among my blogs, I will be covering:

What features did we add in Tracker 1.2 – how can they benefit you?

The difference between URIs, URNs, URLs and IRIs – dispelling any confusion; for the bugs we’ve had reported

Making Tracker more Git-like – we’re moving towards a new ‘git’ style command line with some new features on the way

Preparing for the divorce – is it time to finally split tracker-store, the ontologies and the data-miners?

Making Tracker even more idle – using cgroups and perhaps keyboard/mouse idle notifications

If anyone has any questions or concerns they would like to see answered in articles around these subjects, please comment below and I will do my best to address them!

Recently Carlos added FTS4 and snippet support to Tracker. We merged that to master after doing some tests and have reduced the database size on disk by doing this. I released 0.15.2 yesterday with the FTS4 work, and today I decided to add a richer experience to tracker-search.

Below you can see me searching for passport and sue found in some of the documents indexed on my machine. The colour there is quite nice to separate hits and snippets/contexts where the terms were found. This search without any arguments really will search ALL resources in the database:

This second screenshot shows searching for love with all music in particular. So you can use this for all areas of tracker-search:

With any luck, we will be releasing a 0.16.0 in time for the next GNOME release with this all available in!

Something I have been meaning to do for a long time, is to update the preferences dialog for Tracker to easily add locations which are special user directories (as per the GUserDirectory locations).

I wanted to do this in such a way that:

It was really easy to toggle locations as recursive or not

The file chooser was only necessary for non-standard locations

Better use of the space was made by integrating the two lists (previously) for single directory and recursive directory indexing

I could fix a few issues which had been reported when it came to saving using the special symbols (e.g. &DESKTOP for G_USER_DIRECTORY_DESKTOP, etc.) when one or more user directories evaluated to the same location

Recently I also updated the GtkSearchEngineTracker implementation to not use hacky dlopen() calls and to use DBus instead. This avoids us updating the work for each new version of Tracker that comes along too. The patch attached to the bug (658272) should be applied soon (given Matthias was pushing for this sooner rather than later). So, we’re all on track!

As you would expect, the Firefox extension syncs bookmarks to Tracker (in that direction only for now) and the Thunderbird extension sends email to Tracker to be indexed (even full text content of emails which our Evolution miner doesn’t do because of the system stress it causes). This is really quite superb work from Adrien and tracker-needle already supports bookmarks and emails so it all just works after a make install (into the $prefix where Firefox/Thunderbird are installed). Currently the Thunderbird extension requires version >= 5.0 (works with betas too), and the Firefox extension requires version >= 4.0 (and supports 5.0).

These works have been imported using a pretty cool tool after I felt more comfortable using that to import Adrien’s subtrees into Tracker’s git repository. I did read up on the coolest merge ever from Linus but it felt more like a hack to me to do it that way. Still, I guess Linus knows what he is doing

So now we have both plugins imported with full history into git. The thunderbird branch was merged to master today and the firefox branch will be merged this week hopefully pending Adrien’s review. Great stuff!

GTK+ has had support for Tracker for a while as a backend search engine used in the GtkFileChooser. At GUADEC this year, the Tracker team were asked to update the backend at the GTK+ team meeting. I found time this week to add support and push my changes to the tracker-with-libtracker-sparql branch.

For now, I have dropped support for all older versions of Tracker because it really is a mess to maintain and GTK+ 3.0 should really be using the latest and greatest APIs anyway. The other change I made was to support searching by filenames not the content of files. There is a #define in the .c file (FTS_MATCHING) which allows switching between using FTS (Full Text Search) and filenames (which are usually part of an FTS search anyway). For me, finding a file based on the name itself seems more intuitive for the GtkFileChooser and tends to yield results I am really looking for better than the FTS matching. In most cases, I don’t want to find a file based on some content when choosing a file. I would appreciate any comments on this.