Re: xmltree and mdb

Yes, I see your point.. I didn't try it on directories.

We need a way to know that the cache is incomplete and
therefore other sources should be searched again for 
the incomplete tags.  The cache should also be a union
of queries instead of simply a cache of the last query.

I had thought of time stamping the keys.  The first time 
a key is searched on the timestamp would be 0, and after that
the timestamp would come from the winning metadata source.
However, I didn't want to add the complexity.  Another
way would be to allow searches based on the original algorithm:
look at all the sources until the set of keys is fulfilled
combined with a good default meta datasource (fill all unknown keys
with a default value).

I'll look into it.


On Mon, 2005-05-23 at 21:57 +0100, David Hough wrote:
> On Fri, 20 May 2005 20:58:38 +0100, kristian kvilekval <[email protected]>  
> wrote:
> >
> > I've added checks to make sure we don't search data sources
> > that have not been updated since the last time we cached.
> >
> ...
> >
> > Kris
> 
> I've just been playing around with this, and I've come across a  
> potentionally serious problem. Effectively the metadata tags requested for  
> a particular url the first time a request on that url is made, are the  
> only ones that can be looked up if others weren't found while looking for  
> them.
> For example, if you are browsing a directory in the tree that contains a  
> subdirectory of music, and you double click the sub dir without opening  
> it, the tracks appear blank on the playlist.
> 
> This is becasuse the tree does a request for expandable;playable tags on  
> each track first to check if they should be added to the playlist. MusicDb  
> will then search Cache->MkDatabase->TreeDb and store the  
> expandable;playable metadata in the cache. (Note: I'm assuming the tracks  
> aren't in MkDatabase).
> 
> When the playlist then searchs for title;album;... the MusicDb searchs the  
> Cache and gets a response. However, it then doesn't search any of the  
> other sources as they're all older then the cache, so title;album;... is  
> never found.
> 
> Basically, it's assuming that newer sources always have all the metadata  
>  from all the older sources which isn't always true.
> 
> Unfortunatly, I'm at a loss on how to solve this if we don't store a list  
> of sources that we're searched to generate the cache. Any ideas?
> 
> Cheers,
> David
-- 
Kristian Kvilekval
[email protected]  http://www.cs.ucsb.edu/~kris w:805-893-2526 h:504-9756



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click