On 01/05/11 05:07, Niels Mayer wrote:
On Thu, Apr 28, 2011 at 2:23 PM, Martyn Russell<[email protected]> wrote:
Which applications would be affected? How do I invoke tracker search
on the MeeGo 1.2 netbook (other than command-line)?
There may be some I am not aware of, but the best way to check is to use
Verbosity = 3 and run tracker-store. The logs should indicate who is
sending d-bus requests for *writing* to the Tracker DB. For reading, you
can't tell if apps are using direct access (i.e. opening the DB locally
in process). You can force all processes to use tracker-store in all
cases using the environment variable:
export TRACKER_SPARQL_BACKEND="bus"
You would need to put this in a .bashrc or similar though.
Depending on your version on the device, this situation has been improved
recently.
We've added some measures like: [...]
Thanks. I will definitely look into these once I begin to explore and
better understand tracker's role in various different MeeGo platform
offerings. My comments were about the MeeGo 1.2 Netbook UX on
kernel-adaptation-pinetrail-2.6.38.2-8.2.
I am not in a position to test that right now because I don't have the
hardware here. If you want direct support for Tracker, please contact me
privately as Lanedo can offer that.
I am concerned about your report of ill performance from Tracker though.
It's not what we've experienced in Harmattan for some time now. Can you
provide more details (perhaps in a bug report) to try to improve the
situation?
In some recent updates of tracker, I've found the fan running at times
when I expected the netbook to be silent (it has SSD). Or when it's on
battery. Or using some multimedia apps (e.g. qtractor with various
plugins), openshot, xbmc, that need all of the CPU. That's what
prompted me to disable tracker, until I decide to start using it
explicitly.
There are options to control this. The tracker-preferences application
allows you to configure this,
these are (0.10.x, $HOME/.config/tracker/tracker-miner-fs.cfg)
IndexOnBattery
IndexOnBatteryFirstTime
or (0.11.x/master, gsettings)
org.freedesktop.Tracker.miners.files.index-on-battery
org.freedesktop.Tracker.miners.files.index-on-battery-first-time
Furthermore, I notice it running when I mount external memory cards
and/or network disks (sshfs?), perhaps indexing external disks and
causing unexpected network and processor load.
This is tricky. We have options for that too, but it's sometimes hard to
categorise a "removable device",
these are (0.10.x, $HOME/.config/tracker/tracker-miner-fs.cfg)
IndexRemovableMedia
IndexOpticalDiscs
or (0.11.x/master, gsettings)
org.freedesktop.Tracker.miners.files.index-removable-devices
org.freedesktop.Tracker.miners.files.index-optical-discs
the IndexRemovableMedia is related to IndexRemovableMedia (in both cases
above).
It may need some "throttling" on a MeeGo netbook with SSD-based
filesystem, because the processor has less time to do other tasks
while waiting on the last set of tracker disk I/O requests. And
consequently, higher load associated with the increased disk system
data-rate, than what might be seen on with slower disks. Similar
issues may exist when indexing fast external network disks, alongside
network loading.
these are (0.10.x, $HOME/.config/tracker/tracker-miner-fs.cfg)
Throttle
or (0.11.x/master, gsettings)
org.freedesktop.Tracker.miners.files.throttle
usually, the throttle defaults to 0 but is set to 5 if running on
battery to avoid thrashing devices when power is limited. This also
depends on build time support from HAL or upower.
IMHO, it shouldn't run automatically at all when on battery. The user
should be given a GUI option to control when it runs, or run manually.
Yea, this can be disabled above, the options are also available in
tracker-preferences. Not sure if those are available on your platform
though. Each UI can be disabled specifically at build time.
For resource-intensive programs, or those manipulating the very data
tracker needs to index, something like pasuspender(1) might be useful,
to wrap the invocation of some resource-needing program to prevent
competition for resources. It could also manually run the
tracker-update on completion of the program -- e.g., after the media
being captured or edited can be guaranteed quiescent on disk.
Alternately, as mentioned, an interface that starts/stops tracker
whenever the computer is "idle." I like the idea of a visualizing
screensaver as I like the computer/GUI to have some kind of
representation of what it's doing "under the hood" when some special
resource-consuming process is running. Even better, to have the
"screensaver" provide a visualization of what it's adding to the
information repository, which may help in serendipitous discovery.
An interface to start/stop Tracker is really a geek's toy. Sorry to say
it, but the end user (think of your grandma) doesn't have the first clue
about Tracker and shouldn't need to.
It is a common request recently to have some sort of "index when idle"
option. The down side of this, is that you may not find information
you're looking for immediately. If people can live with this, then it
makes sense.
The tracker-control -F will tell you what's going on, of course there
are signals over d-bus for people to use if they want to have some
indication in their UI about what's going on. On other platforms using
Tracker, that's how they do it, i.e. the music application shows some
progress indicator when files are being mined - so the user knows their
content may not yet be available.
What version of Tracker are you using there?
tracker-utils-0.10.6-1.23.i586
libqttracker-devel-6.12.6-2.105.i586
libqtsparql-tracker-extensions-0.0.7-1.13.i586
libqtsparql-tracker-0.0.21-1.6.i586
qtcontacts-tracker-4.11.8.1-1.5.i586
libqtcontacts-tracker-extensions-4.11.8.1-1.5.i586
libqttracker-6.12.6-2.105.i586
tracker-0.10.6-1.23.i586
libqtsparql-tracker-direct-0.0.21-1.6.i586
libqtsparql-tracker-extensions-devel-0.0.7-1.13.i586
libqtcontacts-tracker-extensions-devel-4.11.8.1-1.5.i586
it appears that the following hasn't been installed by default,
| tracker-upnp | UPnP miner for Tracker
| package
This is not part of Tracker yet, there is a branch which has been
submitted upstream for inclusion, but we've been overwhelmed with work
recently and it hasn't been merged yet.
What makes you think it is Tracker which is causing the problems and not
some other process?
top(1).
powertop(1)
Hope this helps,
Thank you for the information on tracker. I am not trying to "beat up"
on tracker, it's just that my current usage of MeeGo doesn't seem to
require it, and I don't understand it well enough to control it. So it
was easier to just shut it off.
That's fine. I am just checking because we often get reports of "it's
tracker's fault, etc, etc" when actually, it's mis-use of Tracker from
clients or Tracker just shows up in top and isn't the main reason user
of the CPU.
Perhaps due to all the other parts of 1.2 that have been postponed or
removed, it appears that tracker needs better integration into the
current MeeGo 1.2 Netbook UX, and I was too busy getting other stuff
working to notice tracker on the Handset. I do think that "semantic
desktop" and "semantic search" support is a good idea and perhaps some
ideas for "user experience" integration of semantic search/tracking
into the netbook/tablet environment can be taken from KDE's Contour
(Confession -- as a KDE user, I better understand and use its
Tracker-similar facilities, but that's because there's a variety of
apps which make use of its well integrated facilities).
I understand.
We (Lanedo) as earlier mentioned, are offering support services around
Tracker as we have core maintainers working on it daily. If there is
anything needed for specific distributions, we're more than happy to help.
http://transloid.blogspot.com/2011/04/contour-joins-plasma-active-track-get.html
[snip]
According to its developers, the overall goal is to create a
“data-centric user interface which is not concerned with applications
but rather offers intelligently combined data through a
context-sensitive recommendation manager”.
Yes, this indeed makes sense.
[...]
MeeGo will be an initial target platform for the Contour interface.
[...]
The aim of Contour is to integrate what a user it doing on the device,
what “resources” like files and contacts are open, how they are
relevant to running tasks and what applications might be relevant to a
running task.
[...]
///////////////// (see also
http://community.kde.org/Plasma/Active/Contour/Screenshots )
Countour uses Nepomuk (
http://community.kde.org/Plasma/Active/Contour/Technologies#Location_Storage
) and Akonadi for contact management (
http://community.kde.org/Plasma/Active/Contour/Technologies#Akonadi ).
And these are driven by the user from the recommendation manager,
which is the "tie it all together" part that is lacking in MeeGo's
tracker usage: (
http://community.kde.org/Plasma/Active/Contour/Technologies#Recommendation_Manager
):
I agree. It's hard. The Tracker team has a lot of experience talking
with teams from different teams on MeeGo platforms. We've had to because
the technology touches many areas and we get requests / bug reports from
those teams to get their bit working or obtain efficiency.
/////////////////
[...] the recommendation manager, constantly updates recommendations
based on usage patterns, the current context, and recently taken
actions.
Recommendations are passive propositions for actions or information
that are there all the time. Recommendations change over time based on
the changing context and detected patterns. Recommendations are not to
be confused with system notifications for incoming calls, text
messages, or events. They are non-intrusive and can either be accepted
(activated) or ignored by the user. Ignoring a recommendation means to
simply not react on it. Recommendations are specifically not yes-no
questions.
Examples include Contact person X, Open file Y, Start playing music
(this will take into account preferences of the user), Take note about
the phone call just received, Open presentation for the meeting which
you just entered, The next bus to X goes in 10 minutes (When in the
office late at night).
/////////////////
For meego, I also think it would be useful to actually make processes
like tracker running on MeeGo more "direct manipulation" in that
there's a simple way for the user to see that tracker is running, a
simple way to turn it off/on explicitly, and options for automating
whether tracker runs when the computer is "non-idle," or "on battery."
I think a clear approach needs to be taken. You either need to:
1. Index when new data arrives and make the device unavailable until
done (like iTunes).
2. Index as you go and accept that some things may not be available
while indexing is pending (like Nokia's model).
You can allow the user to have more control here, but I don't think they
should care or need to worry about it. I agree, if you're trying to do
something and an indexer like Tracker takes up processor time, it's
bloody annoying and you want a way to turn it off. But that shouldn't be
a user-interaction thing, it should be automatic IMO.
Looking around on the MeeGo netbook, one of the few places tracker is
explicitly used, is in installing the netbook's "sample" media
(copy_file() with the btrfs-clone&& tracker-sparql insert looks like
a pretty interesting MeeGo coding snippet):
.......................
[snip]
Interesting. Thanks for the script.
--
Regards,
Martyn
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
