Tracker – What do we do now we’re stable?

Books

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! :)

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments are closed.

  1. anonim says:

    Hi

    I have 2 questions:
    – Does tracker remove tags (like artists songs names) when the file that contained them is renamed? I’m asking this because AFAIK in the n9 and jolla if I made changes to a mp3 file the old tag info is still stored in the tracker store and the only way to get rid of them is to reindex everything.

    – Can we have a command like “tracker-control -r” but for individual stores? This would be very useful for n9, jolla devices when I want to re-index all music without removing all data (contacts, etc) for the same reason as explained above.

    Thanks,

  2. anonim says:

    I meant when the file is edited not renamed, sorry for the confusion.

  3. George says:

    Help make tracker deal with evolution so we can have a better search of our email.

  4. I recommend fixing all the bugs. ;)

    I turned Tracker on for my ~/local (git checkouts) and ~/build (Fedora package SCM) directories, then after a week or so had to turn it off because the daemon would run my CPU to 100% and exhaust all 16GB of my RAM. So, er, that. ;)

    See also:

    https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&classification=Fedora&component=tracker&list_id=2827098&product=Fedora&query_format=advanced&short_desc=%5Babrt%5D&short_desc_type=allwordssubstr

  5. gg says:

    Ugh?! Stable? I just installed the latest Gnome through ArchLinux repos. And as usual my lappy becomes completely unresponsive as tracker-miner goes berserk.

    It’s eating all my IO: I was compiling latex documents, then tracker-miner began its work right in the middle of that and it took 8 minutes, I mean, **8** minutes to go to the TTY, login and try to kill tracker-miner. But that thing kept respawning itself. It took me 3 more minutes to uninstall it from my system and to kill it a last time.

    It’s true that my home directory contains a **lot** of files of different size (2,599,320, from a few bytes to 20+GB). Some of them are relevant, other are not, but they are there and I don’t want to spend 1 hour trying to whitelist what should be whitelisted. It was much faster and painless to `pacman -Rs tracker`.

    It’s also true that my lappy HDD is painfully slow at times. But that’s no excuse for tracker-miner to eat absolutely all IO. I know this is a kernel thing, but I don’t understand then why `find . -type f | wc -l` that I used to get the count of all my files was not eating all my HDD IO to the point that my system becomes unresponsive. Same thing for rsync which I use to perform incremental and complete backups: the system stays smooth while tracker-miner just makes it unresponsive.

    So no, I wouldn’t say it is stable, at least from the UX POV.

    That said, thanks. Really, without irony.

    Thank you for being innovative and trying to improve UX in Linux and on computers in general. Tracker is really crappy for my use case but that doesn’t mean that it is not great for other use cases or that the idea is stupid. I believe it’s quite the contrary.

    I’m sure Tracker will get better and better and will work well for everyone in a not so distant future. So keep up with the good work! :)

  6. mr says:

    What version of Tracker?

    If you know you’re HD is painfully slow sometimes, you can’t expect Tracker to not be if it’s badly configured. I would suggest it’s probably a combination of crap hardware and Tracker being mis-configured. The default is to not use sched_setscheduler() on initial index, but if you don’t let the index complete, naturally Tracker will use I/O and CPU (unless you configure it differently).

    Finally, stability of Tracker is related to our APIs and comparing Tracker to ‘find’ is like comparing a bus to a plane. I personally don’t like hearing about these sort of experiences and would like to irradiate them. I am most likely going to add another solution for this soon.

  7. mr says:

    Hi Adam, a LOT of the bugs you listed with the RedHat link are due to either:
    a) dodgy files causing excessive memory, disk or cpu use OR b) dodgy or broken 3rd party libraries we depend on.

    Incidentally, we’ve removed the abort/SIGABRT approach for 1.4.x because it’s clear that Tracker is getting a lot of bug reports for weird file/library extractor combinations which are not related to Tracker directly. It’s also the main reason why tracker-extract is a separate process – because we can’t guarantee that 3rd party libraries (like Poppler) won’t cause crashes, memory spikes, etc.

    I should add, the alternative to all of those aborts is we let the process just eat all CPU/Memory.

css.php