Re: xmltree and mdb

I've added checks to make sure we don't search data sources
that have not been updated since the last time we cached.

However, there is a considerable delay on the first
time I open an element of the tree.  Every bit of
metadata is read from my 20gb music tree which is
taking quite a long time even when most of the data
is coming from the metakit database.  

It would preferable if opening the music/playlist/streams item
would only do the minimum number of metadata searches i.e.
one zinf://url?type='P' and then one metadata search for
the icon/title/expandable of each playlist.  Currently
it reads all music including the contents of the playlists.

In a possibly related problem,  when I click to open  
the music/playlist/streams list, 
the entire track list is filled out in the librarylist window.
This might be the root cause of the entirety of the metadata
being read on the fist click.

I don't know if this is possible, but could we
do something like for expandable tree-items.
  on click: 
     if item is a list
        if list is closed, open list 
           else fill out track list
  on dbl click
     same as click, but also add tracks to playlist.


I am not really why this behavior is occurring, it may be 
that the single click is calling TreeNode::get_tracks which
is then doing search down the entire tree.   Any ideas?


Kris

On Sat, 2005-05-07 at 23:54 +0100, David Hough wrote:
> On Wed, 04 May 2005 02:08:09 +0100, kristian kvilekval <[email protected]>  

> This is great, with a noticeable performance boost when browsing my music  
> collection. I've merged it upstream into zinf--xmltree. At some point I  
> should really merge xmltree back into browsermm/CVS, ah well :)
> 
> I have noticed however, that for certain files the Cache doesn't seem to  
> work. I think this is where the file doesn't have full metadata, so the  
> Cache can't provide all the neccessary data, so it looks at all the other  
> sources again to try and find the extra data.
> 
> I seem to remember in a previous email, you mentioned filling in the  
> missing data with some default value if it doesn't exist. Perhaps a better  
> way would be to store which metadata sources were searched to provide the  
> cached data (I notice you've made sure that the sources all have names  
> now), and only continue searching if a source hasn't been searched yet.
> 
> This would provide a generic solution to the problem. So, for instance,  
> data in the "MKDatabase" source could be marked as having cached the  
> source "tags", so when some tags are missing from the database, we know  
> there's no point in looking at the file for them as we already have that  
> data cached.
> 
> I can't help but think that this probably overcomplicates things, but I  
> just thought I'd just mention it.
> 
> 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