Re: [Tracker] No metadata in search results

[jamie <jamiemcc blueyonder co uk>]

On Sun, 2007-07-08 at 22:32 +0200, Laurent Aguerreche wrote:
> Le mercredi 04 juillet 2007 à 02:24 -0700, Brian Davis a écrit :
> > On Wed, 4 Jul 2007 02:13:44 -0700
> > Brian Davis <brian william davis gmail com> wrote:
> > 
> > > Jamie, it's great to have you back. Things picked up in my life as
> > > well and Hum development stagnated a bit. I was cleaning up some bugs
> > > when I realized that the metadata issue I was whining about never
> > > seemed to go away for me. Any calls I make to "tracker_metadata_get()"
> > > return pointers to empty arrays. 
> > > 
> > > I'd love to find out that I'm misusing the API, but the trackerd logs
> > > appear to be properly extracting and returning the correct metadata.
> > > 
> > > You had mentioned a few months ago that this was a known issue. Is
> > > there a fix in the pipeline?
> > 
> > Check that, I am getting file size metadata... but nothing else. 
> 
> 
> I see the same thing here. I tried a RDF query to find musics from 80's
> and did not find anything, but wallpapers are ok (so height and width
> are handled)... "Audio:RealeaseDate" was ignored. Some infos are missing
> in Tracker-search-tool too.
> 
> I looked into database and some metadatas seem to be stored but are they
> stored correctly? And are some data missing?
> For samplerate of a MP3 :
> 
>   ID  ,  ServiceID, MetaDataID, MetaDataValue, MetaDataDisplay
> 286361,    70798  ,     51    ,              ,       44100
> 286361,    70768  ,     51    ,              ,       44100
> 
> Why two different IDs for the same data? Same thing for bitrate. I do
> not see releaseDate or informations about performers of a song for
> instance.
> 
> I used this tool to look into database data:
> http://sourceforge.net/project/showfiles.php?group_id=87946
> 
> 
> Any idea about what is going wrong?
> 
nothing wrong there

Im working on this bug fix for key metadata atm

we cache key fields in the main table for speed but they are not being
stored there during indexing - will have a fix shortly

jamie