> > > >Hum, yes, that's the idea actually; I don't understand why you say it's
> > > >a regression. CREATED and UPDATED events will get merged in the SPARQL
> > > >buffer, and the buffer will be flushed (commited to the store)
> > > >if any of
> > >
> > > Regression means it takes more time than
On 10:01 Fri 15 Oct , Martin wrote:
> On 19:07 Thu 14 Oct , Martyn Russell wrote:
> > On 14/10/10 17:11, Martin wrote:
> > >Hello,
> >
> > Hi,
> >
> > >After trying the alternatives, I found Tracker and I am liking a lot so
> > >far. A
> > >big fat thank you to all developers on this list.
> > >Hum, yes, that's the idea actually; I don't understand why you say it's
> > >a regression. CREATED and UPDATED events will get merged in the SPARQL
> > >buffer, and the buffer will be flushed (commited to the store)
> > >if any of
> >
> > Regression means it takes more time than other branc
On Mon, 2010-10-18 at 20:54 +0200, Aleksander Morgado wrote:
[Cut]
> With the new "miner-fs-refactor-multi-insert" branch, we are merging
> SPARQL updates in a single dbus connection; but still those updates are
> then SQL-inserted one by one in the SQLite database (IIRC, pvanhoof?),
Correct
>
>
> Can you give me some informations why the first part on the code
> fails?
That's actually a GLib issue, in Tracker we're just relying on what
GLib's GVolumeMonitor gives us :-/
--
Aleksander
___
tracker-list mailing list
tracker-list@gnome.
Hello everybody,
In libtracker-miner\tracker-storage.c at:
/* fstab partitions may not have corresponding
* GVolumes, so volume may be NULL */
volume = g_mount_get_volume (mount);
on my host volume is assigned and all goes well. But on my board this step
of getting the volume fails (on the
tracker mailing list is tracker-list@gnome.org
Note that I added it in cc, so no need to forward your previous email to
that mailing list.
I assume you are running tracker-stats on MeeGo platform ?
tracker does not index content in /root .
but in /home/
check config file /home//.config/tracker/t
