Re: xmltree and mdb

On Fri, 20 May 2005 20:58:38 +0100, kristian kvilekval <[email protected]>=
 =20
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 =20
potentionally serious problem. Effectively the metadata tags requested fo=
r =20
a particular url the first time a request on that url is made, are the =20
only ones that can be looked up if others weren't found while looking for=
 =20
them.

For example, if you are browsing a directory in the tree that contains a =
=20
subdirectory of music, and you double click the sub dir without opening =20
it, the tracks appear blank on the playlist.

This is becasuse the tree does a request for expandable;playable tags on =
=20
each track first to check if they should be added to the playlist. MusicD=
b =20
will then search Cache->MkDatabase->TreeDb and store the =20
expandable;playable metadata in the cache. (Note: I'm assuming the tracks=
 =20
aren't in MkDatabase).

When the playlist then searchs for title;album;... the MusicDb searchs th=
e =20
Cache and gets a response. However, it then doesn't search any of the =20
other sources as they're all older then the cache, so title;album;... is =
=20
never found.

Basically, it's assuming that newer sources always have all the metadata =
=20
 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=
 =20
of sources that we're searched to generate the cache. Any ideas?

Cheers,
David
--=20
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/


-------------------------------------------------------
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=3D7412&alloc_id=3D16344&op=3Dclick