Mailing List Archive

Mythmusic Replacement
I have been reading all the mails about Mythmusic lately and am finally glad
to see some others who are also interested in bringing MythMusic into a
trully useable module. Not knocking anyone at all, but the current version
does play music, but leaves a lot to be desired feature and performance
wise. About a year ago I commented on kind of how I would like to see this
module develop out. At the time Thor was working on the MFD stuff and I was
busy otherwise so I kind of took a wait and see attitude.

Well, not much has changed in that time. I am really hoping I can devote
some time to this after the first of the year. Maybe there is enough
interest from different parties to get this going and get it accomplished.

Just as a quick overview of how I see the design - comments welcome:
1) 3 pieces, maybe 4 depending on how you look at it:
A) Master backend server - main purposes:
Delivers music to requestors either streaming or the entire files /
albums / playlists, etc.
Delivers music lists to requestors - one level at a time. No need to
deliver all 4000 available songs, when the person really just wants to play
a single album that they listen to regularly.
Keeps track of stats - how many times played, etc.
This guy is the only one that accesses the database, so it must handle
all database type requests (Save playlists, update playlists, retrieve song
/ music info).

B) Player Daemon
Plays music. Requests next songs from Master Backend. Accepts a
playlist from gui's. This runs in background and thus can play music while
doing other things. Can output to 2nd second card or multiple sound cards.
Can be controlled by any GUI on any machine.

C) GUI's
Multiple's of these, Windows, Linux, Myth plugin. Pretty simple devices.
Provides controls for controlling the player Daemon (Play, stop, pause,
etc). Navigate through music lists via communication with Master Backend
Server.

D) More advanced Linux / Windows music collection controller - want to
burn music, modify playlists, import music, etc - things outside of the
typical tv appliance arena. Things more quickly and easily handled in a
typical pc application environment.


Obviously a pretty big task. My main goals I would like to see
accomplished:
- Make the playing of music easy, fast and enjoyable.
- Greatly speed up the responsiveness of the system. I have a large
collection and when I first go into mythmusic now it takes a long time to
load info about entire collection. Not necessary when all I want to do is
listen to one specific album. I should be able to very quickly navigate
through a tree to get there.
Be able to play music while watching tv, scheduling things, etc...

Once again not knocking anything already done, just see an opportunity to do
make improvements and it seems there are others out there as well with
similar ideals. To me this is not so much a myth project but something else
that provides a plug-in allowing a myth enabled device to connect to and
play content from this music library.

I have been scouring sourceforge and the net for other open source player
projects that might provide a good basis for the centralized master backend
server. No need to necessarily re-invent everything from the ground up.
Found a couple. Still looking.

Hopefully I have time to work on this also with all my other committments.

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: Mythmusic Replacement [ In reply to ]
On Dec 12, 2004, at 7:24 AM, Borg wrote:

> Well, not much has changed in that time.

Not in release, no. But I encourage you to look at CVS of mfd and mfe.

> A) Master backend server - main purposes:
> Delivers music to requestors either streaming or the entire files /
> albums / playlists, etc.
> Delivers music lists to requestors - one level at a time. No need
> to
> deliver all 4000 available songs, when the person really just wants to
> play
> a single album that they listen to regularly.
> Keeps track of stats - how many times played, etc.
> This guy is the only one that accesses the database, so it must
> handle
> all database type requests (Save playlists, update playlists, retrieve
> song
> / music info).

mfd does all of this. It can exchange metadata using either DAAP (same
protocol iTunes uses) or MDCAP (protocol I wrote that does everything
DAAP does, plus lets you send changes in metadata etc).


>
> B) Player Daemon
> Plays music. Requests next songs from Master Backend. Accepts a
> playlist from gui's. This runs in background and thus can play music
> while
> doing other things. Can output to 2nd second card or multiple sound
> cards.
> Can be controlled by any GUI on any machine.

mfd does this. Audio plugin speaks a simple telnet-ish protocol (play,
pause, stop, etc.).


>
> C) GUI's
> Multiple's of these, Windows, Linux, Myth plugin. Pretty simple
> devices.
> Provides controls for controlling the player Daemon (Play, stop, pause,
> etc). Navigate through music lists via communication with Master
> Backend
> Server.

See mfe. Automagically finds any mfds on the local LAN, exchanges
metadata with them, and presents a user interface to play music and
construct playlists. Built using a library (libmfdclient) that does the
hard part of finding the mfd, exchanging metadata, sorting and
preparing it all in separate threads from the main GUI.

A long way from done, but skeleton is there. Main thing holding me up
at the moment is I'm trying to get enough of the new libmythui stuff
finished so that the mfe can be re-written to use that.

>
> D) More advanced Linux / Windows music collection controller - want
> to
> burn music, modify playlists, import music, etc - things outside of the
> typical tv appliance arena. Things more quickly and easily handled in
> a
> typical pc application environment.
>

Nothing like that yet.

> - Make the playing of music easy, fast and enjoyable.
> - Greatly speed up the responsiveness of the system. I have a large
> collection and when I first go into mythmusic now it takes a long time
> to
> load info about entire collection. Not necessary when all I want to
> do is
> listen to one specific album. I should be able to very quickly
> navigate
> through a tree to get there.

See mfe. Only thing happening in the GUI thread is user navigation of
the data. All playing, data exchange, parsing, etc happens in other
threads.


> Be able to play music while watching tv, scheduling things, etc...

Can aleady do that. Control any mfd from any mfe (with auto
discovery). Control audio from any browser
(http://host_mfd_is_running_on:2345/).

>
> Once again not knocking anything already done, just see an opportunity
> to do
> make improvements and it seems there are others out there as well with
> similar ideals.

As I've said elsewhere, I don't want anyone waiting for me. If you
want to write against existing mfd/mfe code, great. If you want to take
ideas from there and implement something new, superb. If you want to
write a better, faster, stronger system from scratch, more power to
you. Just wanted to let you know there's some code there you might want
to look at.

- thor
Re: Mythmusic Replacement [ In reply to ]
I have a question about mfe? I have a couple of 3com audreys that i'd
love to use as a sort of touch screen remote control for the myth box,
I've been trying to figure out how to do it, would mfe be able to
handle that situation, not act as a front end but just a remote
control?
So far i've been looking at hacking up mythweb to fire off cgi scripts
to run particular audio or video??

Mark


On Sun, 12 Dec 2004 16:42:40 -0500, Thor <mythtv@lamedomainname.com> wrote:
>
> On Dec 12, 2004, at 7:24 AM, Borg wrote:
>
> > Well, not much has changed in that time.
>
> Not in release, no. But I encourage you to look at CVS of mfd and mfe.
>
>
>
> > A) Master backend server - main purposes:
> > Delivers music to requestors either streaming or the entire files /
> > albums / playlists, etc.
> > Delivers music lists to requestors - one level at a time. No need
> > to
> > deliver all 4000 available songs, when the person really just wants to
> > play
> > a single album that they listen to regularly.
> > Keeps track of stats - how many times played, etc.
> > This guy is the only one that accesses the database, so it must
> > handle
> > all database type requests (Save playlists, update playlists, retrieve
> > song
> > / music info).
>
> mfd does all of this. It can exchange metadata using either DAAP (same
> protocol iTunes uses) or MDCAP (protocol I wrote that does everything
> DAAP does, plus lets you send changes in metadata etc).
>
>
> >
> > B) Player Daemon
> > Plays music. Requests next songs from Master Backend. Accepts a
> > playlist from gui's. This runs in background and thus can play music
> > while
> > doing other things. Can output to 2nd second card or multiple sound
> > cards.
> > Can be controlled by any GUI on any machine.
>
> mfd does this. Audio plugin speaks a simple telnet-ish protocol (play,
> pause, stop, etc.).
>
>
> >
> > C) GUI's
> > Multiple's of these, Windows, Linux, Myth plugin. Pretty simple
> > devices.
> > Provides controls for controlling the player Daemon (Play, stop, pause,
> > etc). Navigate through music lists via communication with Master
> > Backend
> > Server.
>
> See mfe. Automagically finds any mfds on the local LAN, exchanges
> metadata with them, and presents a user interface to play music and
> construct playlists. Built using a library (libmfdclient) that does the
> hard part of finding the mfd, exchanging metadata, sorting and
> preparing it all in separate threads from the main GUI.
>
> A long way from done, but skeleton is there. Main thing holding me up
> at the moment is I'm trying to get enough of the new libmythui stuff
> finished so that the mfe can be re-written to use that.
>
> >
> > D) More advanced Linux / Windows music collection controller - want
> > to
> > burn music, modify playlists, import music, etc - things outside of the
> > typical tv appliance arena. Things more quickly and easily handled in
> > a
> > typical pc application environment.
> >
>
> Nothing like that yet.
>
>
>
> > - Make the playing of music easy, fast and enjoyable.
> > - Greatly speed up the responsiveness of the system. I have a large
> > collection and when I first go into mythmusic now it takes a long time
> > to
> > load info about entire collection. Not necessary when all I want to
> > do is
> > listen to one specific album. I should be able to very quickly
> > navigate
> > through a tree to get there.
>
> See mfe. Only thing happening in the GUI thread is user navigation of
> the data. All playing, data exchange, parsing, etc happens in other
> threads.
>
>
> > Be able to play music while watching tv, scheduling things, etc...
>
> Can aleady do that. Control any mfd from any mfe (with auto
> discovery). Control audio from any browser
> (http://host_mfd_is_running_on:2345/).
>
> >
> > Once again not knocking anything already done, just see an opportunity
> > to do
> > make improvements and it seems there are others out there as well with
> > similar ideals.
>
> As I've said elsewhere, I don't want anyone waiting for me. If you
> want to write against existing mfd/mfe code, great. If you want to take
> ideas from there and implement something new, superb. If you want to
> write a better, faster, stronger system from scratch, more power to
> you. Just wanted to let you know there's some code there you might want
> to look at.
>
> - thor
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>
>
Re: Mythmusic Replacement [ In reply to ]
On Dec 12, 2004, at 7:21 PM, Mark Friedgan wrote:

> I have a question about mfe? I have a couple of 3com audreys that i'd
> love to use as a sort of touch screen remote control for the myth box,
> I've been trying to figure out how to do it, would mfe be able to
> handle that situation, not act as a front end but just a remote
> control?
> So far i've been looking at hacking up mythweb to fire off cgi scripts
> to run particular audio or video??
>

You could just point a browser on the Audrey at http://mfd_host:2345/,
and use the very crude http interface.

One could conceivably write a full front end for the audrey. If
there's enough CPU power there, it could just be compiled against
libmfdclient. Since that has quite a few threads in it, not sure of the
audrey would be up to it though (?).

- thor
Re: Mythmusic Replacement [ In reply to ]
Hi.
Im rather new to the list, maybe this should go to the wish-list.
Since mp3-players in the modern definition became so popular, wouldn't
it be very nice with
a sub part of mythmusic for editing albums/songs on the /dev/[mp3player].

Just planting a seed..

Br. Fredrik


Borg wrote:

>I have been reading all the mails about Mythmusic lately and am finally glad
>to see some others who are also interested in bringing MythMusic into a
>trully useable module. Not knocking anyone at all, but the current version
>does play music, but leaves a lot to be desired feature and performance
>wise. About a year ago I commented on kind of how I would like to see this
>module develop out. At the time Thor was working on the MFD stuff and I was
>busy otherwise so I kind of took a wait and see attitude.
>
>Well, not much has changed in that time. I am really hoping I can devote
>some time to this after the first of the year. Maybe there is enough
>interest from different parties to get this going and get it accomplished.
>
>Just as a quick overview of how I see the design - comments welcome:
> 1) 3 pieces, maybe 4 depending on how you look at it:
> A) Master backend server - main purposes:
> Delivers music to requestors either streaming or the entire files /
>albums / playlists, etc.
> Delivers music lists to requestors - one level at a time. No need to
>deliver all 4000 available songs, when the person really just wants to play
>a single album that they listen to regularly.
> Keeps track of stats - how many times played, etc.
> This guy is the only one that accesses the database, so it must handle
>all database type requests (Save playlists, update playlists, retrieve song
>/ music info).
>
> B) Player Daemon
> Plays music. Requests next songs from Master Backend. Accepts a
>playlist from gui's. This runs in background and thus can play music while
>doing other things. Can output to 2nd second card or multiple sound cards.
>Can be controlled by any GUI on any machine.
>
> C) GUI's
> Multiple's of these, Windows, Linux, Myth plugin. Pretty simple devices.
>Provides controls for controlling the player Daemon (Play, stop, pause,
>etc). Navigate through music lists via communication with Master Backend
>Server.
>
> D) More advanced Linux / Windows music collection controller - want to
>burn music, modify playlists, import music, etc - things outside of the
>typical tv appliance arena. Things more quickly and easily handled in a
>typical pc application environment.
>
>
>Obviously a pretty big task. My main goals I would like to see
>accomplished:
> - Make the playing of music easy, fast and enjoyable.
> - Greatly speed up the responsiveness of the system. I have a large
>collection and when I first go into mythmusic now it takes a long time to
>load info about entire collection. Not necessary when all I want to do is
>listen to one specific album. I should be able to very quickly navigate
>through a tree to get there.
> Be able to play music while watching tv, scheduling things, etc...
>
>Once again not knocking anything already done, just see an opportunity to do
>make improvements and it seems there are others out there as well with
>similar ideals. To me this is not so much a myth project but something else
>that provides a plug-in allowing a myth enabled device to connect to and
>play content from this music library.
>
>I have been scouring sourceforge and the net for other open source player
>projects that might provide a good basis for the centralized master backend
>server. No need to necessarily re-invent everything from the ground up.
>Found a couple. Still looking.
>
>Hopefully I have time to work on this also with all my other committments.
>
>_______________________________________________
>mythtv-dev mailing list
>mythtv-dev@mythtv.org
>http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>
>