Fetch required service IDs instead of hardcoding.

[ghost]

At the moment, airpnp responds only to devices that provide REQ_SERVICES. Unfortunately, the IDs are hardcoded (and not always is equal to the values in bridge.py).

For example, Syabas Popcorn Hour device will present:

Type: urn:schemas-upnp-org:service:ConnectionManager:1 ID: urn:upnp-org:serviceId:urn:schemas-upnp-org:service:ConnectionManager Type: urn:schemas-upnp-org:service:AVTransport:1 ID: urn:upnp-org:serviceId:urn:schemas-upnp-org:service:AVTransport

And one of the Philips audio streamers will cheerfully report:

Type: urn:schemas-upnp-org:service:ConnectionManager:1 ID: urn:upnp-org:serviceId:ConnectionManagerServiceID Type: urn:schemas-upnp-org:service:AVTransport:1 ID: urn:upnp-org:serviceId:AVTransportServiceID

Airpnp correctly identifies above MEDIA_RENDERER_TYPES but instead of reading the ID it requires the hardcoded ones: 'urn:upnp-org:serviceId:ConnectionManager' and 'urn:upnp-org:serviceId:AVTransport'.

There is a possibility that the devices above are not strictly compliant. Unfortunately I don't think we have a chance of getting the vendors fix their implementations... :(

Perhaps it would be better to fetch the ID from Type instead of hardcoding the two required? I got all the values above using upnp-inspector.

Regards,

grok

[provegard]

Thanks for the report, I'll look into it. Currently I'm busy with a lot of other projects so don't expect anything too soon... :-)

[provegard]

Let me know if the fix works or not. Thanks!

[ghost]

Hi Per,

On 28 Mar 2012, at 23:50, Per Rovegård wrote:

Let me know if the fix works or not. Thanks!

They appear correctly in Bonjour Browser! :)

There's another issue, not sure if you've encountered it.

I use AirFlick to play media from the Mac. Since the devices are presented by the one machine running AirPnP, AirFlick does not differentiate between them and only displays one 'target'. I am almost certain this is a bug in AirFlick.

I don't own any proper Apple devices that do AirPlay, I'm guessing you do and it most probably works as expected (presenting more than one device via the bridge should display both devices to clients and allow them to choose).

Since it's probably AirFlick issue and Mountain Lion is just around the corner, I'm not sure this warrants a bug/feature request in AirPnP. I'll try to get in touch with AirFlick author.

Anyway, thank you for your time, the fix seems to be working, I'll invite some iPhone-equipped friends for dinner so we can test it with decent clients and report back.

Best regards,

J

[ghost]

One more thing:

It may be a good idea to check if a device with the MAC we're about to bridge isn't already advertising that it can do AirPlay. I have a box that can do both UPnP and AirPlay and it's presented twice.

[provegard]

Hi,

Glad to hear it worked!

Airpnp gives different "MACs" to different devices just so that AirPlay clients can differentiate between them. So yeah, you're right that this is probably an AirFlick issue. But I'd be interested in learning what you find out.

I like your second idea, but a problem is that we'd have to rely on the MAC, and where should we get it from? There's no such thing in UPnP, so Airpnp creates a MAC based on the UPnP UDN. But how does your AirPlay+UPnP device create it? I think it's unlikely that it would use the same algorithm as Airpnp does. :-)

If you could send me some information about that device, like the device/root XML and some dump of the Bonjour broadcast/parameters, maybe I can find something out!

Br, Per

[ghost]

Hi Per,

On Thu, 2012-03-29 at 14:06 -0700, Per Rovegård wrote:

Airpnp gives different "MACs" to different devices just so that AirPlay clients can differentiate between them. So yeah, you're right that this is probably an AirFlick issue. But I'd be interested in learning what you find out.

Contacted the AirFlick author suggested to enumerate devices by "IP +deviceID" rather than just "Address", we'll see how that develops.

I like your second idea, but a problem is that we'd have to rely on the MAC, and where should we get it from? There's no such thing in UPnP, so Airpnp creates a MAC based on the UPnP UDN. But how does your AirPlay+UPnP device create it? I think it's unlikely that it would use the same algorithm as Airpnp does. :-)

First, ask bonjour for a list of _airplay._tcp devices:

Service Type: _airplay._tcp Service Name: Haxxored-Player-AirPlay-UPnP Domain Name: local Interface: wlan0 IPv4 Address: Haxxored-Player-AirPlay-and-UPnP.local/192.168.2.17:7000 TXT model = AppleTV2,1 TXT srcvers = 130.14 TXT features = 0x39f7 TXT deviceid =

So we have the IP (from looking up Haxxored-Player-AirPlay-and-UPnP.local in mDNS). We know 'an' IP is provided by UPnP. Is it possible to do "if AP_IP != UPNP_IP then publish else debug '%s already available via AirPlay';"?

Hope I haven't missed something obvious here...

If you could send me some information about that device, like the device/root XML and some dump of the Bonjour broadcast/parameters, maybe I can find something out!

I'm on it. I'll collect proper logs and send them by the weekend.

Regards,

J

[provegard]

You're right, that should work. Would you mind opening a separate issue for this? Thanks!

[ghost]

Bah, was replying to emails, forgot we were talking inside a bugtracker. Will do, thanks!

(hope this doesn't automatically reopen)