[mythtv] MythMusic: MetaLibrarian RFC

[Colin Guthrie]

David wrote:
> 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.

> * permanent music track identity (MD5 of first n blocks of music data -
> something similar already exists I think)
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.

> * other unique keys supported (eg filename) although these may change
> over time
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.


> * 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      |
+------------------------+
|   myth at colin.guthr.ie  |
| http://colin.guthr.ie/ |
+------------------------+