why again are Naim streamers not supporting Spotify?

I think you clearly know why Naim needs to get the indexing right - at any expense. If you look at Sonos, they got the core system absolutely right. The indexing and the proprietary wireless network. Everything else has been built upon that solid foundation. Their mixed source playlists and searches are mind boggingly good and much of this goes back to the indexing approach. I hope and expect Naim will be looking to emulate that. Better to have that and limited features to start with than lots of whizzy features on a shaky foundation. You can always add more features.

Regarding the current streamers specifically, like you I have no idea what the plans are. However, I can see why local indexing might not be one of the features available. I just don't know what the NDS internals are on this side. Do you?

I think if I understand Naim's architecture even a little bit, any development with indexes or such like will come from the controller software.. Ie Nstream. I saw an early prototype version of the new Nstream at the Naim Soho event and it looks and feels quite different... However the online music services were not defined at that time and TJ wouldn't be drawn on which ones were to be included initially.

Nstream will send to the network player (NDX/NDS etc) the media reference and URI address, or a series of URI addresses to the network player to fetch. this could be a music service, UPnP media web radio etc. Although  the network player itself has also very simple media navigator/controller, it might be that higher level navigation functions and services such as music streaming services can only be initiated by Nstream.

Simon

Sonos indexes are held on the streamers. Index updates are replicated across streamers. In this way, any remote controls etc can access the latest index on any streamer which is switched on.

If Naim were to index via N-Stream onto your iThing then just that iThing would hold the index. You would need the space on that device and you would not have the index on any other device unless you provided replication from handheld device to handheld device.

If N-Stream were instead to create an index on the streamer itself, as per Sonos, then that index would need to be held as a file or database somewhere on the Naim hardware. I doubt it is that resource intensive but could build up with large libraries. As said before, I have not looked at the  internals of current streamers and so I don't know what the capability is and hence cannot comment on viability.

So, in either of Naim's two alternative indexing options, some new software is needed and the appropriate hardware to hold the index. I think the crux of the matter is whether they replicate from handheld to handheld or hold indexes on the streamer and replicate to any other streamers. The latter seems the neater approach and is the one Sonos have used to great success.

I can't imagine any circumstance under which Naim would want to create and maintain a new indexing scheme for existing streamers and another one for new streamers (Muso).

You may be right in that existing streamers do not have the capability to take it on. I don't know. Do you have access to the specs?

If it were me, I would build Muso in emulation of the Sonos approach (assuming I couldn't license the software from Sonos directly). Index on the streamers. I can't see how holding the index on an iThing etc is a good idea.

Seems as if one would require a significant amount of semi-volatile storage (in flash, of course) to retain a tree of all found music, along with an expiration time for each item (after which the streamer would go out and verify the resource, fetching a DIDL along the way).  This is not impossible, by the way, to implement on any UPnP device (or combinations thereof), provided that the Content Directory, AVTransport, &c. services are exposed to a generic (wireless) control point.

It happens all the time - wireless networks can be slow and local caching of parts of a ContentDirectory tree can be quite useful to improve apparent responsiveness for a control point app.

It isn't a good idea as the main indexing scheme for the application we're discussing.

Where multiple devices are used for control. as is common nowadays, the situation you describe is sub-optimal as it creates a need to replicate across handheld devices.

Most streaming services (Pandora, for certain), MOG, Spotify, etc. support higher bandwidth streams via PC/Mac browsers due, preusumably, to better system resources than smaller devices (phones, ipods, etc).  Further, you can stream each of these services in a browser on your Mac, and output either USB/SPDIF to the Naim (I use UQ2) and it will do a marvelous job presenting the music for you (be sure to go into the settings of your Mac/PC and change output to NAIM if it doesn't "see it" automagically).  I understand that this solution is not as eloquent as what most of you were hoping for, but its technically is still streaming, and its better quality than some other options. For Mac users, try both USB and headphone output-to-SPDIF to see which one the NAIM likes better. (I've only tried USB so far so I couldn't tell you).

Hi,

I use Qobuz but Spotify works probably in the same way.
I would also like to send my Qobuz music on my Qute. So I started to develop a Mac app for that.

For the moment, I succeed to send one song at the time to the Qute. For an unknown reason the Qute need to be in iRadio mode or USB mode.

It's really a basic app, then I can't choose precisely the song that I want to play but it works.

I could make a alpha version if any of you wants to try.