Re: [Tracker] Too much pain with Evolution 2.24 and Tracker 0.6.9x
- From: Martyn Russell <martyn imendio com>
- To: Laurent Aguerreche <laurent aguerreche free fr>
- Cc: tracker-list gnome org
- Subject: Re: [Tracker] Too much pain with Evolution 2.24 and Tracker 0.6.9x
- Date: Sun, 15 Mar 2009 10:20:59 +0000
Laurent Aguerreche wrote:
Hi,
Hi Laurent,
first congratulations for Tracker 0.6.91!
Thanks :)
But I experience many troubles with Evolution 2.24.5 for a long time
(before Tracker 0.6.90): after a moment, Evolution loops forever when it
tries to download mails, or when I delete old mails, or even when I want
to read some. If I kill Evolution, I cannot restart it immediately
except if I logout from the session and then I reopen a session before I
start it again.
It should be said that the current solution of looking into the database
and trying to deduce what Evolution sees is a really bad idea. This is a
temporary solution and we are asking for pain if we stick with it.
Evolution can do whatever they want here with the database schema (i.e.
change it).
Are you able to debug this at all and give us any indication of where
the problem is?
It is only recently that I found that tracker-indexer is guilty. In
fact, Evolution stops to loop forever when I kill tracker-indexer.
"evolution-imap-db.c" uses sqlite3_open(). Perhaps SQLite3 opens
Evolution's databases as read-only databases? Or, is Fedora 10 SQLite3
that uses particular parameters?
There might be some issues here. We haven't received many/any? reports
of anything like this yet. Maybe it hasn't been used by many people yet.
I certainly haven't had any issues with it yet but I am not a heavy user.
I use latest Tracker version of trunk.
We have another solution in TRUNK too, which allows evolution to push
the data to Tracker instead of Tracker dipping in and pull data from
Evolution's database. This was done by Philip. Unfortunately the change
requires a newer version of Evolution and to be configured to enable in
Tracker (since Evolution hasn't been released yet? with these changes).
As soon as possible, we will use this method since it is much more
reliable than the current solution.
--
Regards,
Martyn
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]