list children crashes if the DMS do not provide a ContentDirectory Service

[markdryan]

This is a weird one. I encountered this problem testing against a DMR that was claiming to be a DMS, i.e., it claimed to be a MediaServer1 device but it implemented AvTransport instead of ContentDirectory. dLeyna-server discovered the device correctly but crashed when attempting to perform a list children. It crashes as it always assumes that the service proxy is non NULL. As the service proxy is NULL the action is not created. We then complete the task but we don't have an error object either so we crash.

My feeling is that we should fix this by simply not exposing devices that do not provide a content directory service. Then the rest of the dLeyna-code that assumes that the service proxy is not NULL will be correct.

[lferrandis]

Maybe we should take a look at the "service-available", "service-unavailable" notification.
What happens if the service become unavailable after a while, when the device is already published?

Should we manage an internal list of published/unpublished device, depending of some criteria? (Only service available?) So if the service become once again available, we move it from one list to the other, and make the device public again.

I didn't look at the code already, but similar mechanism don't already exist with LPC?

[markdryan]

I think you are probably right. Wow, this is going to make device discovery even more complex. We'd need to have some sort of holding queue for MediaServers that don't support ContentDirectory.

Alternatively, we could simply check the proxy before issuing calls and fail if is NULL. I'm not sure which is more confusing for the user. DMSs that don't appear in the list or DMSs that do appear but cannot be browsed.

[lferrandis]

On 25/09/2013 10:22, markdryan wrote:

I think you are probably right. Wow, this is going to make device
discovery even more complex. We'd need to have some sort of holding
queue for MediaServers that don't support ContentDirectory.

Alternatively, we could simply check the proxy before issuing calls and
fail if is NULL. I'm not sure which is more confusing for the user. DMSs
that don't appear in the list or DMSs that do appear but cannot be browsed.

—
Reply to this email directly or view it on GitHub
#133 (comment).

We could also send notification error. Applications can register or not,
and can decide to display the problem to users.. or not..

We can implement something like:

1 - We register for "device-available" notification.
2 - When a new device is notified, we register for
"service-available"/"service-unavailable"
3 - We build the dleyna-device object and put it in the "Pending Service
queued"
4 - We set up a 2 sec timeout callback "Notify Error"

At this stage we have 2 solutions:

A - We receive the "service-available" notification
1 - Delete the NotifyError cb
2 - Move the dleyna-device from "Pending Service queued" to "Active
Device queue"
3 - Notify "Device Available"

B - We don't receive the "service-available" notification
1 - The NotifyError cb will trigger. We will send an error about the
device that doesn't have needed services.
2 - We keep it in the "Pending Service queued".

This solution has many advantages:

1 - It still work during the lifetime of an active device. If the
Content Directory Service is an independent daemon that crashes on the
device, we will receive "service-unavailable" notification. We can then:
1 - Send a NotifyError
2 - Move it to "Pending Service queued".

If the device restart automatically the service, we will receive
"service-available" notification. And then goto option A)

That should answer to your issue: "DMSs that don't appear in the list or
DMSs that do appear but cannot be browsed."

• We only display DMS that can be browsed.
• If we found a DMS that can't be browsed (at discovery or when
  running), we provide a way to display a reason. So applications have the
  choice to silently hide broken DMS... or not.

Ludovic Ferrandis
Open Source Technology Center
Intel Corporation

[jku]

Crashing if services aren't implemented is pretty serious: at least that would be great to get fixed: the improvements on when to expose a device would be nice but secondary.

[jku]

It is indeed a bit complex... I think we really should not expose any devices until we know we can offer an API that actually does something: in other words exposing a Device for a DMS that does not implement ContentDirectory does not make sense (so I agree with @lferrandis)

[jku]

The device construction is really complex already (unfortunately also undocumented)... I'd really like to not make it more complex. What if we did not look for a UPnP device at all but connected to "service-available" for "ContentDirectory", then figured out the root device and continued as we now do in prv_device_available_cb() ?

Basically, let's not care about devices until they advertise a ContentDirectory service, which is the one crucial service that dleyna-server is interested in -- everything else we look at or might look at in future is optional but ContentDirectory isn't. If the service goes unavailable, we forget all about the device as well.

As for " DMSs that don't appear in the list": I don't think that's confusing if we document that only reasonably compliant devices are listed... A DMS without a ContentDirectory isn't really a DMS.

[rsbells]

I agree Jussi we should only handle devices that are advertising a ContentDirectory service...