Re: metadatabase

Kristian Kvilekval wrote:
> The old metadata system would spawn a thread, just as you say.  I am 
> not sure that the new browser actually needs this as we only request
> the metadata when actually displayed (this can slow down scrolling
> on slower machines).   However, the fixes mentioned above which
> should stop slower/costly search at the end of the metadata hierarchy
> should alleviate this.


I am pretty sure someone fixed the way the old catalog would render the 
list, making reading the db extremely fast and also obscoleting any need 
to read on demand.
It's a database file, reading it even for 6000 songs  all at once is 
barely noticable and more efficient than reading it a little at a time. 
  The file is not all over the hdd, it's a single file. Multiple time 
spanned reads is less efficient than a single one and since this is done 
on load of zinf, it's hardly noticable.
The "lazy" db code you wrote was to address this problem of zinf taking 
forever to start because it was reading the db wrong.  The other fix was 
much more simple and to the point though, actually fixing the problem 
instead of finding a way around it. Yea, it sucks to put a lot of time 
into code that just gets replaced by someone else, but really there is 
no need to read the db on demand, when the db is merely a MB or so.




Zinf in itself is Ugly, unwieldly, and bloated with unused code that's 
been forgotten about.  Adding this new system on top of that is just 
doubling your work and slowing the progress of getting the new system up 
to par.  I think you need to tear the old system out completely, call 
this a new new branch started at when the new system was committed 
(basically breaking zinf anyway) and continue development that way. 
Win32 can either continue on at the old branch or decide to port the 
makefiles to use libboost for win32.  Technically, there should be only 
code ommissions that need to be done in win32 land as all the new mdb 
code is completly portable code and should reside in a non-arch specific 
location in the zinf fs.  I like the idea of less and less arch specific 
code in zinf's base system but changes in the UI not being compatible 
with win32 are unavoidable.  Win32 has gtk2 libs, it would be easier to 
jump over to use that than continue to worry about keeping UI after UI 
up to date, it would be just as stable.

You'll get no where fast if you wanna keep everything working all the 
time.  Actually you'll likely go backwards. Windows NT and Windows 9x 
existed side by side, people in win9x couldn't get the benefits of NT 
until they moved to it and the programs they used were ported to it. 
The point is you can have the current pre-new-mdb zinf as that branch, 
compatible with windows users and all, and have zinf 2.5 as the dev 
branch on the road for say...2.6 or whatever.  Either way, 2.5 doesn't 
have to "work" but it should be a the correct starting point for the new 
mdb code, and that means tearing out the old code everywhere it exists. 
  While you're at it, tear out every other obscoleted function that 
hasn't been removed for fear of reverse compatibility too. If you get 
them all zinf would probably be half the code size it is now. something 
like that.



As a side note though, my player works with URI's from the ground up and 
uses libmagic to determine the codec of the stream pointed to by the URI 
(file network device).  I haven't gotten to the playlist part yet, just 
finishing up a skeleton pipeline with file input plugin, passthrough 
decoder plugin and null output plugin. Things have slown down due to 
tests at the moment.
Once i'm done with the skeleton pipeline I'll finalize my API 
specification for all the subsystems (one i have now is sort of 
informal) and I can move on to the other things like playlist / metadata 
/ preferences / ui.  Not trying to convert any developers working on 
zinf to help with my code, I haven't released any code and i dont plan 
to until I have a functional proof of concept,  but I want to debate 
ideas to see how other developers think things should be done if they 
could get it the way they want it, like what's going on in this thread. 
  That way i can save everyone time by having my code able to be what 
most developers want so when it is ready to be used full time it can be 
a very attractive alternate - clean codebase for people who want to work 
on a audio player but dont want to have to have the entire program's 
function visualized in their mind to add a feature.

So yea, lets see some definitions and specifications on what a playlist 
should be, why does it have to be different from a metadata manager and 
  under what method should the UI be hooked into the whole thing and 
anything else relating to it.

to me :

Playlist: human readable text list of streams playable to the the player
Playlist Manager: container that creates a list in the player consisting 
of translated playlist entries such that a UI can correctly display the 
entries.
metadata manager: container that retrieves, accesses, removes, and 
possibly writes metadata related to lists of streams given to it.


Playlist would be an object or array of objects private to Playlist 
Manager.  Metadata manager would be inherited by Playlist Manager. Such 
that say to get the current track to be played you'd have a call to the 
Playlist manager like 
playlistManager->getStream("file:///home/mysong.ogg"); Retrieving 
metadata if available is taken care of implicitly by getStream by simply 
calling this->metaManager->getStream("file:///home/mysong.ogg"); which 
only accesses the database.  A separate update method can be used in 
metadata Manager to update entries in the database as opposed to 
researching directories for files and such and adding them to the 
database.  These should be done explicitly by the user and not used when 
simply reading the db for displaying a playlist.   etc etc.  Some 
feedback would be cool.




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php