Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[herr_schneider]

Dear all,

I have a BubbpleUpnp server exposing some DLNA devices as OpenHome Renderer. While my android phones using BubbleUPNP can see those devices, all MC instances - acting as control points - do not see those. Windows somewhat sees them but classifies as "unknown devices"...

Should MC be seeing the OpenHome renderers? If yes - can you hint me at some place I can start investigating why they are not seen?

If no: is there thought / intention to start supporting OpenHome UPNP renderers? As of now, I am using bubble upnp as control point because I love the versatility of OpenHome renderers, but I'd like to combine MC and its power with those renderers....

[AndrewFG]

^

Can you please explain what is an "OpenHome" renderer? I never came across that term before in relation to UPnP / DLNA.

[herr_schneider]

OpenHome is an extension to the UPnP protocol. The main differentiator - afaik - is that the current playlist resides on the renderer, making it independent from the control point, allowing for multiple control points to access the renderer and pause, stop and continue playback independent of the control point.

See http://openhome.org/wiki/OhMedia#ohPlaylist.

BubbleUPnP Server allows for arbitrary renderers in the network to be exposed as OpenHome renderers (http://bubblesoftapps.com/bubbleupnpserver/#media_renderers_configuration and http://bubblesoftapps.com/bubbleupnpserver/#openhome_intro), which is what some people also over here do, according to what I have found in the forums. Being able to target such OpenHome renderer directly from within MC would allow using all the advanced features of zone linking etc. Besides the fact that I would only need one type of control point...

[bob]

It was initiated by Linn IIRC and it has some nice features, chiefly the playlist support which is a more elegant way to do gapless as well as letting the controller get out of the picture once it's started a playback process.
I took a look at the docs a few years ago and started implementing it however it has almost no support amongst renderer manufacturers (only Linn AFAIK) and that doesn't seem to have changed in any significant volume in the last few years. The bubble idea of shimming it over a regular UPnP renderer is interesting and seemed to work pretty well with the limited testing I did with it.

[AndrewFG]

It was initiated by Linn IIRC and it has some nice features, chiefly the playlist support which is a more elegant way to do gapless as well as letting the controller get out of the picture once it's started a playback process.

I took a look at the docs a few years ago and started implementing it however it has almost no support amongst renderer manufacturers (only Linn AFAIK) and that doesn't seem to have changed in any significant volume in the last few years.

Ah yes. The Linn extensions. I also looked at them and decided not to implement them. My reasons were as follows:

1) Just a minor correction: these are extensions to UPnP and but they are not extensions to DLNA. DLNA is itself an extension of UPnP, and the Linn extensions go in another direction. Indeed if a manufacturer wants to certify its product as DLNA compliant, it would probably not be possible get that certification if that product also implemented the Linn extensions..

2) Those extensions were anyway a futile effort. They are vendor specific methods added to the UPnP specification. Instead of joining the UPnP forum and trying to introduce those extensions into the normal specification process, Linn tried to go behind the back of the members of the forum and go it alone. Obviously all the other member companies were not impressed with such arrogance.

3) Linn did not understand the UPnP specifications in the first case. They did not realise that v1.0 of the UPnP DMR specification a) did already allow gapless playback via SetNextAVTransportURI, and b) it did already allow a Control Point to push a playlist to a renderer via the SetAVTransportURI method. The SetAVTransportURI can take two types of argument, namely either 1) the URL of a single media file, or b) the URL of a .PLS or .M3U playlist file (for example). So the Linn extensions were an attempt to "solve" problems that did not actually exist...

4) If Linn would have joined the UPnP forum and/or the DLNA industry group, they would have learned that v2.0 of the UPnP DMR specifications do themselves extend on the v1.0 capabilities, with additional methods for Control Points to add & delete individual items in a playlist, and additional methods for synchronised playing. So Linn is now trying to push a non standard vendor specific "solution" that a) was not needed, and b) now has worse capabilities than v2.0 of the main-line UPnP and DLNA specification.

Personally I am not betting any money on Linn winning this..

[IMGrant]

I would like to see OpenHome support in JRiver too, mostly because it just works well.

The points AndrewFG raises are interesting, I did not know most of that, and it's true, the 'right' way to go sounds like it would be DLNA v2.0 if that indeed does do playlists.
However, I don't know any devices that implement this? OpenHome is gaining some traction - it is used in Linn's DS players (obviously), but also in a handful of other niche hardware players, and there are now also good software solutions (a Java-based player, an interface to MPD).
Out of all the solutions to this problem, OpenHome seems to the most widely supported and it is available for anyone to implement.
Many companies seem to have developed their own solutions: Naim players do on-device playlists I think (no idea how, must be something proprietary), Sonos does (again, proprietary). However, is there any device or software program that has implemented the current 'right' way to do it of pushing and pulling playlists as described? I don't know of any.

Adding OpenHome to JRiver is also rather unintrusive - if talking to an OpenHome device, those interfaces would be used, if a regular DLNA device, it would fall back to feeding tracks one-by-one as usual.

It seems like the thrust of opposition to this would be that it might encourage manufacturers to implement OpenHome (at the expense of DLNA v2.0).

[AndrewFG]

It seems like the thrust of opposition to this would be that it might encourage manufacturers to implement OpenHome (at the expense of DLNA v2.0).

Hmm.

There is no "thrust of opposition" here (at least not from me). I am just suggesting that you face reality; the DLNA organisation has about 200 active members who have produced about 3 billion certified devices; if you imagine that those people are likely to abandon that momentum in favour of a "one horse show" then ... dream on ...

[bob]

... Sonos does (again, proprietary). However, is there any device or software program that has implemented the current 'right' way to do it of pushing and pulling playlists as described? I don't know of any.

The Sonos device we have does DLNA that supports SetNextAVTransportURI which allows gapess playback.

[AndrewFG]

I think that IMGrant was asking if renderers exist that accept an M3U or PLS playlist being pushed to them; frankly (apart from Whitebear) I never checked it..

[bob]

I think that IMGrant was asking if renderers exist that accept an M3U or PLS playlist being pushed to them; frankly (apart from Whitebear) I never checked it..

Sorry, I think I have seen one or two but IIRC you can't really do metadata properly with that flow...

[AndrewFG]

but IIRC you can't really do metadata properly with that flow...

I know. As I recall there are two variables used -- namely CurrentURIMetadata and CurrentTrackMetadata, the former is supposed to pass ALL of the DIDL associated with the uri passed in SetAVT.. (so if the uri is a playlist file it contains the DIDL of all tracks in that playlist), and the latter is what the renderer uses to inform the CP about the metadata of the now playing track. The renderer is supposed to sort this out. But I bet they don't...