Fetching latest commit…
Cannot retrieve the latest commit at this time
|Failed to load latest commit information.|
mfd - Myth Frontend Daemon Release 0.?? GENERAL INFO ------------ INSTALL (see DEPENDENCIES): ./configure qmake make make install ldconfig RUN: to start it: mfd -l 10 (log with verbosity equal to 10) to stop it: mfdctl stop You can just CTRL-C the mfd and it will shut down cleanly. If it's in daemon mode, you'll need to use mfdctl stop. DEPENDENCIES ------------ The mfd essentially has all the dependencies of MythTV plus MythMusic and (probably by the time you read this) MythDVD. In addition, you will also need: LiveMedia Library http://www.live.com/liveMedia/ Any reasonably recent version should be fine. There's a debian package called liblivemedia-dev, and almost certainly packages for other distributions as well. Note that this is not _strictly_ required (you can turn it off with ./configure --disable-rtsp), but is very, very highly recommended. You can set the directory prefix for live with --with-livemedia-prefix=foo (if you've built the liveMedia library from source (NB: it has no "make install") in, say /usr/local/src, then you probably want --with-livemedia-prefix=/usr/local/src/live/). FAAD2 library http://www.audiocoding.com/ __NB__: As of March 5, 2004, you can build and install FAAD2 v2.0 final, but you must manually copy mp4ff_int_types.h from faad2/common/mp4ff/ to your usr/local/include/ directory. This is fairly annoying, but not insurmountable. OpenSLL Also required is openssl (for generating unique identifiers for content files). This should be included with just about any Linux distribution. OpenDAAP Library You'll also need libopendaap if you want to play iTunes content. Make _sure_ to get the right version. Also, make _sure_ you read the daapclient plugin README for further details (./mfd/plugins/daapclient/README). INFORMATION FOR DEVELOPERS -------------------------- The mfd is not terribly complicated. There is a core little object (called MFD) that main() creates and hands over control to. It creates a metadata server to be the holding pen for all metadata (a collection of MetadataContainers). It also creates a plugin manager. Plugins can either present their own (socket-based) interface to the world, or get passed commands that begin with a given token from the mfd. For example, the audio plugin has it's own interface, while the dummy plugin just uses the mfd's interface and asks for any string of command tokens that begin with the term "dummy". The former is called a "service", the latter a "capability". Every plugin (can! must?) run as a separate thread. They can and do create their own sub-threads. Most information they want to pass up to the mfd is send by QCustomEvents (see mfd_events.h/.cpp in mfdlib). If they need to describe metadata (appearance of, changes in), they get a pointer to the MetadataServer and make calls on it. The mfd itself speaks a protocol called mfdp (mfd protocol). This is a classic example of YAMUP (yet another made up protocol). The audio plugin speaks macp (myth audio control protocol ... which is also YAMUP). Most importantly, the metadata server embedded in the core mfd object speaks a protocol called mdcap (Myth Digital Content Access Protocol). This is what lets frontend clients figure what content a given mfd has on offer. See ./mdcaplib/README for a few more details. Here's a list of client side mfdp commands (by the time you read this, it will probably be out of date). Note that you can play with these at a telnet prompt (e.g. telnet localhost 2342). hello Ask the mfd to say hello. Should send back "greetings". halt Make the mfd shut down and exit. quit " " shutdown " " dummy This just gets passed to the dummy plugin. It will respond with "dummy exists" (assuming the dummy plugin exists, which it should.) You can also send it the command "dummy die". It will then generate a FatalEvent, causing the plugin manager to unload it. reload Ask the mfd to make the plugin manager reload all plugins. This will send "restart" to every connected client and anything the plugins were in the process of doing will be shutdown and cleaned out. Normal clients should not do this. services list Ask the mfd to send "services found ... " messages to you listing all the services it is aware of. These are things that plugins do on their own sockets. capabilities list This is a list of first tokens that either the mfd itself or one of its plugins can handle via the mfd's socket interface. These obviously have the effect of increasing this list of client side commands (!). The following are commands that the mfd can send to any client **at any time**. That means your code (where "you" are a myth client developer) needs to be able to act appropriately: huh If you send something that the mfd (and/or its plugins) can't parse, you'll (probably?) get back "huh", followed by the set of tokens it didn't understand. bye Your socket connection is about to be closed because the mfd is exiting (user killed it, machine is shutting down, etc.) restart All the plugins are being killed and reloaded (mfd probably got a reload command). Anything you had going on (a video transcode, music playing, etc.) will get killed and cleaned up. The socket will stay open, however, so you can rebuild whatever you need to get back to where you were. fatal Some plugin had a fatal event (it freaked out and had to be unloaded). If it didn't happen to be (one of) the plugin(s) handling your requests, then nothing should change. However, it may well be that something you were expecting to happen will not. services found ... Some new service has been automagically discovered. services lost ... Some service that used to exist has gone away. You may have to update *lots* of internal data. capability foo If you send some commands beginning with the token foo, there is a plugin that will swallow them.