Re: UPnP base driver instability

[Stefano Lenzi <ki...@interfree.it>]

Jackson, Bruce wrote:
> Hi Stefano
> 
> I'm far from happy with the way the base driver actually works in various
> areas, particularly subscriptions. 

We have recentlty worked on some internal code of the CyberLink library 
regarding the UPnP Subscription. So we may have fixed even your issues.

What kind of problem have you expierenced?

I've thought about doing a completely new
> implementation of the diver, but this a pretty major chunk of work, and from
> my researches so far, it may be that the problems really result from the
> fact that CyberLink does all of the HTTP stuff manually, i.e. By opening
> sockets and writing bytes.

Have you considedered the idea of wrapping other Java UPnP library such as:
  - upnplib (http://www.sbbi.net/site/upnp/)
  - weupnp (http://code.google.com/p/weupnp/)
  - extracting code from the Vuze/Azureus project

Our initial idea was to use CyberLink only for short period of time and 
the create an abstraction library which could allow the developer to 
select the prefered upnp library. But, unfortunatly we never had the 
time to complete that.

> 
> So, as an interim measure, I'm currently replacing the low-level HTTP packet
> code with Apache HTTP core to see how that performs. I'll let you know how I
> get on.

Have you had any luck in replacing the HTTP code?

> 
> Regards
> 
> Bruce
> 
> 
> 

Re: UPnP base driver instability

["Jackson, Bruce" <br...@qualcomm.com>]

We've developed a completely new UPnP driver based on a some of the code in the JEMS media server from code.google.com, but refactoring it entirely to be a "proper" implementation for OSGi. We're testing this right now, and also working through with our legal people how we can contribute this back to the community. This has many advantages: its much smaller, seems to be more reliable and compatible with UPnP/DLNA devices and also fixes many of the issues we ere seeing with subscriptions etc.

Hopefully I'll have some more information about a possible release to the community (if, of course this is considered by all of you to be interesting) in the near future.


On 26/03/2009 10:36, "Stefano Lenzi" <ki...@interfree.it> wrote:

Jackson, Bruce wrote:
> Hi Stefano
>
> I'm far from happy with the way the base driver actually works in various
> areas, particularly subscriptions.

We have recentlty worked on some internal code of the CyberLink library
regarding the UPnP Subscription. So we may have fixed even your issues.

What kind of problem have you expierenced?

I've thought about doing a completely new
> implementation of the diver, but this a pretty major chunk of work, and from
> my researches so far, it may be that the problems really result from the
> fact that CyberLink does all of the HTTP stuff manually, i.e. By opening
> sockets and writing bytes.

Have you considedered the idea of wrapping other Java UPnP library such as:
  - upnplib (http://www.sbbi.net/site/upnp/)
  - weupnp (http://code.google.com/p/weupnp/)
  - extracting code from the Vuze/Azureus project

Our initial idea was to use CyberLink only for short period of time and
the create an abstraction library which could allow the developer to
select the prefered upnp library. But, unfortunatly we never had the
time to complete that.

>
> So, as an interim measure, I'm currently replacing the low-level HTTP packet
> code with Apache HTTP core to see how that performs. I'll let you know how I
> get on.

Have you had any luck in replacing the HTTP code?

>
> Regards
>
> Bruce
>
>
>