[mythtv] Mythbackend UPnP server?

David Blain MythTv at TheBlains.net
Wed Jan 18 22:47:54 UTC 2006

Wow, there seems to be a lot of interest for upnp!
Instead of responding to each e-mail individually, I will try to answer all
questions in this e-mail.
1) Make what I have available now:
I will try to get something available to use ASAP.  However, I don't want to
rush the integration of the code too much.  I want to make sure that the
solution I have come up with is clean and a good design.  Nothing worse than
making bad design decisions just to "make it work".  I want this to be a
part of MythTv and not just a feature bolted on its side.  
Either way, if I find I can't spend enough time on it due to real life, I
WILL put the source on a web page for others to carry on.
2) Am I using libupnp?
No.  I decided not to use it for the follow reasons:
  a) I didn't want to introduce another dependency into MythTv.
  b) I wanted more flexibility to leverage the same code for direct http
query string (REST) access.  So clients that are not upnp aware, and don't
want the overhead of SOAP, can use the same web service calls.
  c) If I understand correctly, libupnp is based on source code that Intel
developed.  It's main goal was for embedded systems, and therefore generated
to fit a specific application.  This would make it difficult to extend to
addins without regeneration.  
  d) Since Intel released V2 of the library under a very constrained
license, I don't want to promote use of their V1 code. (mini temper tantrum)
  e) Most of all I wanted the experience of developing all aspects of the
upnp layer from scratch.  (learning experience)
3) Use UPnP Discovery for locating multiple Frontend & Backends.
Definitely!  I was not going to implement this in my first release (not
planning any changes to MythFrontend), however, it should be extremely easy
to use the classes I created to implement it.
4) MythBackend as a MediaServer.
This is exactly what the first release will accomplish.  I am NOT
implementing the MediaRenderer service. (something for MythFrontend if
everyone feels upnp is a good choice for it).
5) Other UPnP Services...
Not planning implementing any of them at this time... nothing stopping
someone else too though.
6) Support for other UPnP Devices (renderers/clients)
Yes & No... My goal is to allow any UPnP device to be able to discover and
access content on any number of MythBackend systems.  However, since there
has not been any standardized DVR Service defined, the "Off The Shelf"
devices will not understand how to schedule recordings.
If a standard service ever gets defined, it would not be difficult to add
support for it.  In the meantime, I am implementing my own MythTV DVR
Service that any client can leverage if they are made aware of it.
7) Open issues:
One thing that I don't have time to implement that is needed for off the
shelf devices to work is an implementation of a standard transport stream.
I was thinking RTSP/RTP.  
I am planning on having only 2 <res> types to start with:
  Myth://     (normal Myth Protocol... would be used if MythFrontend was
designed to use uPnP & windows would need dsmyth to use)
  Http://      (Need to test to see if my HTTP 2.0 server implementation can
handle multiple video stream while maintaining uPnP tasks)
It's good to see this many people interested... I will try and keep the list
posted on my progress.
David B.

More information about the mythtv-dev mailing list