Re: [Tracker] [PATCH] Moving towards internal metadata extractors

[Laurent Aguerreche <laurent aguerreche free fr>]

Le mercredi 27 septembre 2006 Ã 11:51 +0100, Jamie McCracken a Ãcrit :
> Samuel Cormier-Iijima wrote:
> > On 9/27/06, Jamie McCracken <jamiemcc blueyonder co uk> wrote:
> > > Samuel Cormier-Iijima wrote:
> > > > On 9/26/06, Edward Duffy <eduffy gmail com> wrote:
> > > > > Update to that last patch with exif enabled.
> > > > >
> > > > > On 9/26/06, Edward Duffy <eduffy gmail com> wrote:
> > > > > > Here's the patch for moving everything to tracker-extract.
> > > > > >
> > > > > > On 9/26/06, Jamie McCracken <jamiemcc blueyonder co uk> wrote:
> > > > > > > Edward Duffy wrote:
> > > > > > > > Is there any advantage to keeping them internal?  Should we just
> > > > > stick
> > > > > > > > with tracker-extract for all types?
> > > >
> > > >
> > > > ...
> > > > I just reindexed all my files with an up-to-date CVS tracker, and the
> > > > CPU usage skyrocketed to 90%. Is this possibly because all the
> > > > extracting is done in tracker itself, so we lose things like nice -19?
> > >
> > > trackerd runs at nice +10
> > >
> > > only text filters run at nice +19
> >
> > That's weird.. then how come it was hogging so much CPU? (I have about
> > 200 GB of stuff, but the last time I indexed usage didn't go above 10%
> > or so)
>
> it should not hog cpu - if you dont have other process using cpu of 
> course tracker will try and use it.
>
> we are doing stuff like zipping contents which is cpu intensive I guess.


I saw that yesterday when I tried to shutdown trackerd. It was in a
infinite loop in tracker_db_save_file_contents():

#0  0xffffe410 in __kernel_vsyscall ()
#1  0xa7cb75ab in read () from /lib/tls/i686/cmov/libc.so.6
#2  0xa7c5a5f8 in _IO_file_read () from /lib/tls/i686/cmov/libc.so.6
#3  0xa7c5b9a8 in _IO_file_underflow ()
from /lib/tls/i686/cmov/libc.so.6
#4  0xa7c5c0fb in _IO_default_uflow () from /lib/tls/i686/cmov/libc.so.6
#5  0xa7c5d3bd in __uflow () from /lib/tls/i686/cmov/libc.so.6
#6  0xa7c51666 in _IO_getline_info () from /lib/tls/i686/cmov/libc.so.6
#7  0xa7c515af in _IO_getline () from /lib/tls/i686/cmov/libc.so.6
#8  0xa7c5053f in fgets () from /lib/tls/i686/cmov/libc.so.6
#9  0x0805d0d7 in tracker_db_save_file_contents (db_con=0x8096b80,
    file_name=0xa5e01430 "/home/laurent/a_file", info=0x8258c00)
    at tracker-db-sqlite.c:1354
#10 0x0804f148 in extract_metadata_thread () at trackerd.c:1118
#11 0xa7de436f in g_thread_create_full ()
   from /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../libglib-2.0.so.0
#12 0xa7d31240 in start_thread ()
from /lib/tls/i686/cmov/libpthread.so.0
#13 0xa7cc629e in clone () from /lib/tls/i686/cmov/libc.so.6


It was trying to read 'a_file' with fgets() but 'a_file' is actually a
link to a directory!

I don't have time to investigate this problem but can you try to make
trackerd index a directory where a symlink to another directory is
present?



Laurent.