So, to answer that question first: Tracker tracks the user home and any mounted media that is attached to the device. For the memory cards, it retains a stack of 3 cards in it's database, so, you can change card A to card B, and back to card A and tracker won't need to reindex the content of the cards. And yes, you can be then swithing to B, to A, to B and you won't lose any data. The amount of cards to support is a configuration option, but by default it's set to 3. So, internal card=1, external card1=2 and then you have the one more as exteral card2. For a third external card, the device will need to flush the oldest seen card away from it's indexes.
There was some concern also as to whether applications can put sound effects and pixmaps into the cards and to make sure they won't be indexed. Well, to this, we have two solutions:
1. put the files to a folder that is hidden (so, it has a "." in the beginning of the folder name) - tracker won't index any hidden folders by default
2. Add the folders to trackers blacklist file
I recommend the solution 1 for multiple reasons.
1. it's simple.
2. user doesn't have any reason to see application data anyway, so this way it'll be also hidden in the file manger. Just make sure your app will flush the data on uninstall of your app.
Ok, then a bit on how you can use Tracker.
As you probably have read, I've been on paternity leave, from which, I've taken a bit of time to integrate ukmp to the new Fremantle stack.
So, first thing I did was, I replaced my own indexing code with code to load all music metadata from tracker database. Loading of this data on startup takes almost no time and tracker also does sorting of the data really easily for me. Not that sorting would actually be any issue in python, nice anyway.
On startup, I hear you saying? Why not on demand? Sure, that would be an option, just happens that how ukmp was built, it's easier for me to get all the content on startup and not on demand. Both are fine. I could write a small comment on how to do stuff on demand as well, but let's start with this.
We'll need to use two interfaces: search and metadata
Corresponding dbus introspection files are: search and metadata
You can find the whole dbus introspection from here
Let's start with defining the needed proxy objects:
bus = dbus.SessionBus()
searchproxy = bus.get_object('org.freedesktop.Tracker','/org/freedesktop/Tracker/Search')
#Ok, let's then get all music files and for those, the artist, album, title and track# sorted by artist
metadata=searchproxy.Query(-1, "Music", ["Audio:Artist","Audio:Album","Audio:Title","Audio:TrackNo"],"", dbus.Array(, signature='s') ,"",False,["Audio:Artist"], False,0, 40000)
#Now that we have the data, we'll just add it to the internal structures
for songItem in metadata:
self.appendSong(track, album, artist, song, fileUrl)
Nice and simple. Now we have the data. This saved me about 300 lines of code, plus multiple library dependencies and tons of headache.
Of course, with my approach of loading everything on startup, I need to update the data when the data changes, but for this, tracker provides a really nice signal that looks like this:
signal sender=:1.15 -> dest=(null destination) serial=403 path=/org/freedesktop/Tracker; interface=org.freedesktop.Tracker; member=ServiceStatisticsUpdated
I won't show the implementation on how to keep the data update on this blog post, I'll save it for a future blog post. I'll instead now tell how to keep Tracker up-to-date on usage of the files. All media players on Fremantle should either use MAFW or do the following so that we would all be happy campers no matter which media player user uses.
When you are playing a music file, please notify tracker of the play event. I do so at the end of a track, but your heuristic may vary. Firts we get the current playcount, then we add 1 to it, then we set the new playcount and the curren playtime. We set the time in GMT in UTC format, which is rather easy to get in python.
if len(currentCount)>0: newcount=int(currentCount)+1
Ah, now we have the data in tracker, we are able to update the playcounts and playtimes so that all music players can benefit from the data. In my next blog post, I'll tell how the album art can be handled in common way across the platform. I'll tell you how you should do it and I'll tell you how I do it now (which might not be the case I will do when the device has been out for a while).
Then I'll make a blog about how to make dynamic lists, e.g. to list most popular tracks, most recently added and the most recently played tracks.
Then, to top this, I'll let you know how the signaling can be used to keep your internal data structures up-to-date, in case you are not using on-demand loading of the data.
edit: fixed typo as noticed by timeless