[mythtv] [mythtv-commits] mythtv commit: r14781 - intrunk/mythtv by nigel

[David]

> 
> Hi David.
> 
> 
> > Mediarenderer should not be moved to libmythupnp.
> > It's specific to mythfrontend
> 
> At the moment, but once I do the final changes,
> any MythContext using program can use it.
> 
> 
> > and would cause problems if other applications used it at the
> > same time.
> 
> Just because of the server port duplication, yes?
> 

BTW: it would be simple to allow for each application to use a different
port.

> 
> 
> Assuming that two programs
> (say, mythwelcome and mythfrontend)
> were to start up at the same time,
> the first one would create the renderer,
> and the second would fail.
> 
> I will be adding code to destroy the
> first program's renderer once it has
> got the ConnectionInfo via UPnP.
> 
> That should mean that the second program
> can then be restarted , and it can have
> its minute in the UPnP renderer spotlight.

That won't work.  The MediaRenderer upnp device/service is meant for
mythfrontend only.  It is not used for autodiscovery at all.  It's for
future support in controlling mythfrontend from a remote control point.
(ie: send it a command to start playing a video.)  At this time, none of the
MediaRenderer service methods/details are implemented.  

Also note: each upnp device/service gets a unique GUID to identify itself.
Control points can then use the GUID to locate and register for state
variable event notification.  This event subscription would be for a
specific device/service.  If the control point connected to mythwelcome, and
then it went away and was replaced by mythfrontend, all subscriptions would
be invalidated and all the control points would lose access to the device.

I do agree with you that the autodiscovery code should be shareable with
other applications, but as stated above, the MediaRenderer class is not
needed for it. 

If the desired functionality is to allow for a control point to access all
of MythTv (all plugins), then some sort of master device needs to be
implemented that is always running and can forward requests from the control
points to the various plugins  (I was thinking mythfrontend would be the
master program, but I didn't take mythwelcome into consideration).

> > Also, I kept masterselection out of the libmythupnp because it
> > contains UI
> > code.  I'm trying to keep the upnp library a pure protocol
> > implementation.
> 
> Fair enough. Putting it in libmyth if the other option.
> I will revert that change now.
> 
> --
> Nigel Pearson, nigel at ind.tansu.com.au|Well, I own the hotel