<p>Just a thought but linuxmce uses mythtv extensively what I thought was a comprehensive upnp server. Maybe it is time well spent to investigate this and if it makes the grade look at incorporating there changes back into mythcore?</p>
<p>R</p>
<p>Please excuse brevity and mistakes, this email was composed on a mobile phone.</p>
<p>Thanks and regards,<br>
Richard Morton<br><br><br><br></p>
<p><blockquote type="cite">On Oct 8, 2009 3:35 AM, "Mark Kendall" <<a href="mailto:mark.kendall@gmail.com">mark.kendall@gmail.com</a>> wrote:<br><br>2009/10/8 Jeremy Palenchar <<a href="mailto:jeremy@palenchar.net">jeremy@palenchar.net</a>>:<br>
<p><font color="#500050">> Would you consider migrating over to one of the other stacks if the
> licensing is compatible or d...</font></p>I spent some time looking at, and to a lesser extent working with,<br>
libmythupnp a couple of months ago.<br>
<br>
My focus is very much on the frontend though - with a view to adding<br>
playback of content from other upnp media servers, media renderer<br>
support for mythfrontend and a full html remote interface (by way of<br>
the presentation element of upnp). (the last 2 together also have the<br>
interesting side-effect of controlling frontends with other<br>
frontends). All of this was put on hold until post 0.22 though.<br>
<br>
The major issue with adding media renderer support is (as you mention<br>
below) tracking the frontend's state. This will require a fair amount<br>
of work (and agreement) and to my mind reinforces the need for a upnp<br>
stack that is tightly linked to the frontend code.<br>
<p><font color="#500050">
> I looked at the uPnP specs a little bit yesterday and there is a lot that
> needs to be done in t...</font></p>I'm not sure whether you mean that there is a lot to be done<br>
generally to be upnp compliant or whether libmythupnp needs a lot to<br>
be done. As I said to David a while back, I like his upnp stack - it's<br>
clear and well written imho - and, from memory, any missing<br>
functionality that I spotted could be added fairly painlessly. It's<br>
also worth bearing in mind that upnp is a pretty static target - the<br>
spec isn't changing rapidly and hence once you have a library, it<br>
should be pretty much stable for an extended period of time.<br>
<br>
In case anyone isn't clear on that, my vote goes with libmythupnp :)<br>
<br>
But this is all pretty irrelevant to the original topic anyway - on<br>
the fly transcoding is something that you bolt on behind the scenes -<br>
and would be/should be entirely invisible to the upnp stack.<br>
<br>
regards<br>
<font color="#888888"><br>
Mark<br>
</font><p><font color="#500050">_______________________________________________
mythtv-dev mailing list
<a href="mailto:mythtv-dev@mythtv.org">mythtv-dev@mythtv.org</a>
http:/...</font></p></blockquote></p>