Naim app and upmpdcli (or the other way round)

The Naim app only works with Naim streamers. 

The Linn Kazoo app needs an OpenHome compatible renderer. Try installing BubbleUPnPServer which will create a "proxy" OpenHome renderer from any UPnP server. (Though as Lunin works upmpdcli is already working as an OpenHome renderer so I'm not sure). 

As a PS. Are you sure you need upmpdcli now: I thought UPnP renderer capability had been integrated into mpd. 

Eloise posted:

The Naim app only works with Naim streamers.

Oh, this is a bit disappointing! Any obvious reasons why this is so? Thanks, nbpf

Trying to think of the best answer to this... The Naim app is specific to and designed to control the Naim streamers and streaming devices...  I suppose if somebody made a streamer that worked like a Naim streamer the Naim app might work with that Streamer...

Simon

Eloise posted:

As a PS. Are you sure you need upmpdcli now: I thought UPnP renderer capability had been integrated into mpd. 

I do not know. If http://www.lesbonscomptes.com/pages/mpd-upnp.html is what you are referring to, than I'm not sure this is a viable approach for me.

My main motivation for installing Minimserver and upmpdcli was to be able to take advantage of proper tagging of my data and of Minimserver's support for custom tags and "intelligent browsing".

If I were to make MPD a client of Minimserver (in contrast to making MPD an engine of upmpdcli) I would have to rely on MPD clients for searching and browsing my files. But MPD and MPD clients support browsing classical music collections very poorly, which is the reason why I turned to Minimserver.

Thus, the current approach -- Minimserver as a full-fledged UPnP server, upmpdcli as a renderer and MPD as a upmpdcli slave -- seems to be a canonical solution to my original problem.

I might be mistaken, of course and I am interested in trying other approaches. But I do not want to loose the advantages of MPD and Minimserver.

Best, nbpf

Simon-in-Suffolk posted:

Trying to think of the best answer to this... The Naim app is specific to and designed to control the Naim streamers and streaming devices...  I suppose if somebody made a streamer that worked like a Naim streamer the Naim app might work with that Streamer...

Simon

 

I very much hope that the Naim app is specific to the Naim streamers and works particularly well with them.

But this does not necessarily imply that it cannot honour UPnP or other specifications. I understand that UPnP is poorly specified and I am not making any specific criticism.

I'm just wondering why Linn and Lumin work (almost) perfectly and the Naim app does not even get to see the renderer, not even if one manually sets the correct IP address: not very cooperative ... 

Quite informative wrap-up and short assessment of the advantages and disadvantages of Apple, Squeeze, MPD, UPnP/DLNA and OpenHome streaming approaches, written by the main author of upmpdcli:

http://www.lesbonscomptes.com/...t-audio.html#ohmedia

nbpf posted:

 

I'm just wondering why Linn and Lumin work (almost) perfectly and the Naim app does not even get to see the renderer, not even if one manually sets the correct IP address: not very cooperative ... 

I think the crux of it is that Linn took the UPnP spec and decided to make is better (eventually renaming it OpenHome).  The big limitation to standard UPnP which Linn looked to overcome was that playback was controlled by the control point where OpenHome introduced the concept of a playlist stored on the player - this allowed multiple control points to view and edit the playlist and enabled the control point to be turned off once the playback had been started.  By contrast with non-OpenHome control points, if you close the control point playback (on a Naim player for example) will typically stop after the current track.  

Lumin and Auralic then copied Linn, using Linn's open source code.

This is something which has been copied by others including Naim, but no one else has released their method as a open standard the way Linn has.  So basically Naim's app is not a UPnP control point; its a Naim streamer controller - though some of that control does use UPnP protocols (thats why it doesn't work with non-Naim streamers).

The original UPnP specification allows for the media to pushed to or pulled from the renderer... and also allows multiple control points... So nothing new in this regard fromOpenHome here......... there is so much mis information on UPnP. It is simply a set of procedures or methods and a protocol that can be used by Application software.. The core UPnP specification is very very flexible which is why profiles such as DLNA profiles and possibly OpenHome have been created that arguably limit this flexibility but thereby increasing interoperability for their own market, uses or commercial reasons.

The Naim app is a UPnP control point... It is designed to work with Naim renderers that pull their media from the media server.

Simon

Eloise posted:

nbpf posted:

 

I'm just wondering why Linn and Lumin work (almost) perfectly and the Naim app does not even get to see the renderer, not even if one manually sets the correct IP address: not very cooperative ... 

I think the crux of it is that Linn took the UPnP spec and decided to make is better (eventually renaming it OpenHome).  The big limitation to standard UPnP which Linn looked to overcome was that playback was controlled by the control point where OpenHome introduced the concept of a playlist stored on the player - this allowed multiple control points to view and edit the playlist and enabled the control point to be turned off once the playback had been started.  By contrast with non-OpenHome control points, if you close the control point playback (on a Naim player for example) will typically stop after the current track.  

Lumin and Auralic then copied Linn, using Linn's open source code.

This is something which has been copied by others including Naim, but no one else has released their method as a open standard the way Linn has.  So basically Naim's app is not a UPnP control point; its a Naim streamer controller - though some of that control does use UPnP protocols (thats why it doesn't work with non-Naim streamers).

Thanks for the very interesting comments and explanations Eloise! 

I hadn't realized that standard UPnP does not store the playlist on the player, now it is clear why mconnect does not support gapless replay with upmpdcli whereas Linn Kinsky and Lumin do.

It's a bit disappointing that the Naim app does not support the OpenHome protocol, I had fancied buying a Qb for the kitchen at a certain point ...

But the Lumin app works very well with upmpdcli and fully supports Minimserver.

Thanks again for having made me aware of Minimserver! The lack of support for tagging classical music was the only complaint I had with MPD. From what I could demo at different Naim dealers I was also under the impression that the Naim app would not be suitable for searching and browsing classical music collections. This was a false impression although, to my defense, I have to add that Naim's support in this area is very poor, that the documentation for the Naim app is virtually inexistent and that many Naim dealers do not rely on Minimserver and properly tagged classical music collections for their demonstrations.

For me, Minimserver has been the most significant improvement to my system since the Ovator S400!

The only disadvantage that I can see is that Minimserver is not open source. On the other hand, documentation is exemplary and the support seems to be very good.

I have started supporting Minimserver with a small donation. If the project maintains its current standards, I will divert some of the money that I would have spent for hardware upgrades to the project.

Simon-in-Suffolk posted:

The Naim app is a UPnP control point... It is designed to work with Naim renderers that pull their media from the media server.

I'm not sure I agree with this statement Simon ... surely if it was a UPnP control point it could control other UPnP renderers ... which it can't.

The Naim app is the same as apps from Pioneer and Marantz in that they tell the streamer what files to get from the server.  If it was a true UPnP control point it would be telling the server what files to send to the renderer.

nbpf posted:

Thanks for the very interesting comments and explanations Eloise! 

[...]

It's a bit disappointing that the Naim app does not support the OpenHome protocol, I had fancied buying a Qb for the kitchen at a certain point ...

If you want to use an OpenHome control point with a Naim renderer, then you can setup BubbleUPnPServer which presents a OpenHome compliant proxy to the control point and serves the music to any UPnP renderer that way.

Eloise posted:

nbpf posted:

Thanks for the very interesting comments and explanations Eloise! 

[...]

It's a bit disappointing that the Naim app does not support the OpenHome protocol, I had fancied buying a Qb for the kitchen at a certain point ...

If you want to use an OpenHome control point with a Naim renderer, then you can setup BubbleUPnPServer which presents a OpenHome compliant proxy to the control point and serves the music to any UPnP renderer that way.

Thanks, Eloise, I'll keep in mind this possibility! The next step for me is to finalize adding "work", "conductor" and "orchestra/ensemble" tags to the collection. At the same time I am looking for a iOS control point that does not display irrelevant information, just the 'indexTags' values I have set in Minimserver's configuration. Best, nbpf

Eloise posted:

Simon-in-Suffolk posted:

The Naim app is a UPnP control point... It is designed to work with Naim renderers that pull their media from the media server.

I'm not sure I agree with this statement Simon ... surely if it was a UPnP control point it could control other UPnP renderers ... which it can't.

The Naim app is the same as apps from Pioneer and Marantz in that they tell the streamer what files to get from the server.  If it was a true UPnP control point it would be telling the server what files to send to the renderer.

Eloise, not at all, there is no requirement for a DLNA/UPnP control point to generically control DLNA/UPnP renderers, which is why there are so many profiles. Even Sonos uses UPnP to control its devices. But If you conform to a UPnP subset profile, then yes you would expect interoperability with other devices conforming to that specific profile. 

What you describe is just the UPnP media server push method, a true UPnP controller can equally use the renderer pull method, which is the mode that Naim have decided to use. This method Naim use can be referred to the DLNA 3-Box model and uses a MDR or renderer. If you use push method, the you use a MDP or music player rather than a renderer.. according to the DLNA architecture.

Simon

Simon-in-Suffolk posted:

What you describe is just the UPnP media server push method, a true UPnP controller can equally use the renderer pull method, which is the mode that Naim have decided to use.

Simon, does this imply that the Naim app should not be able to discover upmpdcli?

Hi, from what I can see upmdcli is a software UPnP renderer.. now the Naim app will be looking for Naim devices in its renderer discovery routines (streamers,  Muso etc) .. so almost certainly it will see the upmdcli respond to the Naim app controller discovery requests but I would expect the Naim app to disregard everything other than valid Naim devices.

Simon

nbpf posted:

The upmpdcli renderer (http://www.lesbonscomptes.com/upmpdcli/index.html) works flawlessly with Linn Kinsky (iOS), the Lumin app (iOS) and a few other control points for iOS and Android. But not with Linn Kazoo (iOS) and not with the Naim app.

Are there any known reasons why the Naim app (for iOS) does not recognize upmpdcli?

Short update: Linn Kazoo does recognize the upmpdcli renderer if this is turned into an OpenHome renderer via BubbleUPnP Server.