I'd say 'cached' in an indexed on-disk format.
hehe, OK i'll say cached next time ;)
Is it worth breaking the functional areas down? * Enhanced Metadata storage/access * standardised schema * read/write(-thru) to native mp3/flac/ogg tags, lyrics, art
yup, yup, yup.
not something I'd thought as far as but this seems very sensible, especially if you mix a few Non MetaLibrarian aware apps into the mix, or randomly rename a file yourself.* permanent music track identity (MD5 of first n blocks of music data - something similar already exists I think)
yup. Assuming it does not supply music data itself, the filename would be a required argument to any audio player app. I think I have previously mentioned that it would need to have file path equivalents if the mount points of the music data are different from client to server.* other unique keys supported (eg filename) although these may change over time
* Services * search/filter * sort (by x/y/z etc) * stored/static lists (m3u/playlists) (stored using the permanent key, possibly presented using filename key...)
yup * 3.
* dynamic lists/views (heirarchies/random/mood/suggested)Yes. Random probably the odd one out as this could be left to the client application. As for that matter could the suggested tracks. The MetaLibrarian could just act as an aggregator for the raw data in relation to playcounts/skipcounts/score etc. but it could be left up to the application to actually use it?
* notification (change/new)Yeah definatly. New tracks magically appear in your app. One of the cooler features of DAAP etc.
* stream/serve files? (probably not initially but if you want to do RPC type things then why not provide the raw data aswell?)
No reason not to I sps. But this may be better achieved by writing a closely linked companion DAAP server rather than reinvent that particular wheel? I'm open to further thoughts on this one.
* Management * ui/api to create lists * ui/api to create dynamic lists * image grabbers for albums etc * lyric grabbers ... * FreeDB access? * file management (ie rename/move mp3s)
To be honest, I'm not immediatly convinced by the "ui" requirement. I was kinda thinking that the API would allow client apps to create their own UI to control this. Keeps the project in it's place and doesn't "steal" functionality from the applications that it wants to integrate with it.
Image/Lyric/Bio/Reviews grabbers would all be good. Probably linking to the MusicInfo package which already has this functionality :) (I think that's what it's called. Prokyon3 uses it).
What other solutions are there? * Amarok * madman * xmms * taglib
Taglib is particularly interesting as it aims to be a low-level API in the same sense as MetaLibrarian.
Yes I was secretly thinking that MetaLibrarian would either link against or swallow up the TagLib sources in some capacity.
It is well placed to provide a simple upgrade route if you can offer the abstraction required by eg Amarok. (I wondered about slicing Amarok's DB system off - it already supports both mysql and sqlite so I expect some abstraction there. It may also be a suitable candidate for working the metalibrarian abstraction layer idea. Finally it may also provide a nice gui for later... It is written in Qt so it may be a place to grab lots of good code from even if there's no immediate Amarok/Myth marriage :) )
Yup that too is my underlying hope. I've not looked too closely at the Amarok source (just a few simple CVS backports for Mandrake patches), but I am hoping that it would be a reasonably simple process to integrate support. It would be quite a substancial change for Amarok tho' so would need the full support of their developers.
Although Isaac wasn't keen on depending on Taglib last october I don't think the time has come to rule it out just yet - especially given the stated aims of MetaLibrarian.
If e.g. MetaLibrarian swallows up TagLib and MySQL/DB client code properly such that MetaLibrarian is one library to link against then this is only one dependancy. Theoretically Myth could then swallow up libmetalibrarian as libmythmetalibrarian to ensure that all the code is self contained within Myth. Either that or MetaLibrarian becomes so amazingly brillient that everyone wants to use it and therefor the extra dependancy doesn't seem like a chore ;)
Thanks for taking the time to split things out like that David, it is very useful.
I'm really liking the feedback I've received so far which has mostly been cautiously optimisitc. Most people seem to like the general concept, although are quite rightly concerned with how hard it will be to get others to support it. I guess a bit of pre-development marketing with other dev lists may help help gauge the general feeling?
Finally, apologies to anyone who doens't like this discussion on the Myth list. I know it is kinda off topic, but this was the best place I could think of to post this discussion in order to find like minded developers.
All the best
Col.
--
+------------------------+ | Colin Guthrie | +------------------------+ | [EMAIL PROTECTED] | | http://colin.guthr.ie/ | +------------------------+
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
