[mythtv] Proposed Change to MythMusic

Joseph Caputo jcaputo1 at gmail.com
Tue Jul 10 17:37:24 UTC 2007


On 7/9/07, Daniel Burr <dburr at veritel.com.au> wrote:
> On Mon, 2007-07-09 at 20:26 +0100, Stuart Morgan wrote:
> > Lets get this straight - I won't ever support such a move towards a cobbled
> > together solution involving different projects, that's taking things entirely
> > in the wrong direction IMHO. Now some might accuse me of re-inventing the
> > wheel by persisting with mythmusic but I'd rather design the right wheels for
> > mythtv than build a vehicle with wheels from a cart, a bicycle , a wonky
> > shopping trolley and a tractor. You might just end up with a working
> > application for a month or two but it would be a bitch to maintain and even
> > harder to setup for the end user.
>
> What if upstream mpd could be factored out into a library + app?

It already is... libmpdclient is the client library that communicates
with an mpd daemon.

> Obviously you're not adverse to using libraries (taglib, flac) so this
> could allow MythMusic to have more advanced functionality using a
> relatively stable external API.  MythMusic provides the wheels but we
> get to have the engine of a Ferrari and the body of a BMW.

That's basically what I've already suggested... and I completely
understand about not wanting to cobble together a system from too many
different parts.  Traditionally, that's not how Myth has done
things... that's more of a Freevo approach.  And I'm absolutely all
for building out internally written/maintained frameworks.  However,
there've been no significant changes to the MythMusic architecture in
the past couple of years... mfd has basically been abandoned... I'm
not pointing any fingers, I just think that utilizing already existing
pieces can get us where we want to be quicker.  If someone is stepping
up to the plate and dedicating themselves to revamping MythMusic (and,
to some extent, Myth's audio subsystem in general), then great.  If
not, maybe someone who finds that to be a daunting task would be more
likely to step up and "cobble together" a framework of existing
components.  There's also no reason why both approaches couldn't
co-exist as different plugins.

One of my main pet peeves is that I **don't like** managing my music
collection within Myth.  I'd much rather maintain it elsewhere and
just let MythMusic worry about reading a playing it, without having to
worry about setting up an NFS or a CIFS share. A lot of time and
effort has gone into MythMusic features like ripping, scanning,
tagging and maintaining the music DB... effort that could have gone
into enhancing the UI & general browsing/playback experience.  But
that's just my opinion, and since I'm not stepping up to the plate to
develop the code right now, I'll just leave it at that.

-JAC


More information about the mythtv-dev mailing list