[mythtv] MythMusic: MetaLibrarian RFC

[David]

Colin Guthrie wrote:

> David wrote:
>
>> * 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?

By this time I'm thinking of the architecture around ML.
A service layer/area seems an obviously non-core and modular way to go.
If some services store static lists then fine - others may store 
parameters for algorithms like : genre or bpm driven 'random'
Because they're modular you just write a list generator and advertise it 
to clients - then *any* client can take advantage and not have to write 
their own
The core thing is you say 'give me a list of lists' then 'next 5 from 
list X'
X is just a name in the list of lists - the client doesn't care what 
_kind_of list.

I'm not saying ML delivers all this - just that when anyone writes a 
playlist service, it can be used by any app.
ML is the framework.

>> * 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.

Indeed. I was thinking about clients that were too dim to have full 
blown nfs/smb setups. My phone over bluetooth maybe... (one day - the 
point being not to constrain the design yet)

>> * 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.

More architecture layering.
I'm not saying ML delivers this either - you're dead right that others 
do this stuff - but the ML framework will ensure that when a playlist 
manager creates a view/playlist, Myth can use it. The intention is to 
understand what doesn't need doing.
Myth's frontend is a crap place to browse and drag'n'drop lots of music 
into playlists - sure you can do it but it's not nice.
Mythweb is a step in the right direction but really something like 
anarok with a full gui is the place to do a full blown playlist manager.
Then Myth can do a very basic editor and any other conforming manager 
(including mythweb) can do playlist editing.

>
> 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.

and Taglib itself makes a point of being agnostic and having no onward 
dependencies.
I think ML may fit well conceptually into the Taglib/KDE ethos...

>
>> 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.

True.

> 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?

What about prototyping with taglib's oo model and the architecture 
above, seeing where that goes.
Maybe look to Amarok's design for ideas.
Then see about getting a strawman design up for comment?

David