Any known Naim app issues? (Mu-So & Star)

Reboot your router, and power down the devices. Power the router back up and try again. The App is very temperamental.

I have been trying for a few hours.  Spoke to retailer this morning and they had problems (at that point my app was fine).
And as if by magic, I posted on this forum and it all came back.  
I was trying to delete my post 

Thank you for reponsding Lord Hillier 

Pleasure Pal. Enjoy!

The apps aren't connected in any way, so if you have a problem today that you don't normally have and I have a similar problem today that I don't normally have, it's not that something central has gone wrong with the app. It's coincidence. The app is talking to your kit over your network, not back to some server somewhere like Facebook or WhatsApp or even like a central heating control app.

The advice about restarting stuff including in particular the router is always good. But you would almost certainly get the same result much faster by stopping and restarting the app. In IOS you double click the home button, swipe the app upwards, click the home button once and then restart the app. Nine times out of ten it will work properly then in my experience.

Also I really don't agree that the current version of the IOS app is "very temperamental". It has its moments occasionally but on the whole it works pretty well and reliably in my experience.

best

David

Not recognising / not finding streamers on the network may be indicative of some network config issues.

Current verison of the app (5.9 for iOS) has no problems with finding ‘rooms’ almost instantly.

The app is plain awful in my opinion. Software is not one of Naims strengths by the looks of things.

It’s easy to dismiss something as ‘plain awful’. What exactly is wrong with it? I use it day in, day out, and it does everything it should. It works every time, lets me find my music or radio station, and works the multi room perfectly. 

Hungryhalibut posted:

It’s easy to dismiss something as ‘plain awful’. What exactly is wrong with it? I use it day in, day out, and it does everything it should. It works every time, lets me find my music or radio station, and works the multi room perfectly. 

+1

When the app works (almost) perfectly for many (probably most) people, it makes it hard for Naim to improve the app for people it doesn’t work for as the problems are caused by variations in networking (and yes I know the argument is your network works for everything else why does Naim have problems).  

The app works fine for me as well - it does everything it says it will do just about everyday that I am home - and importantly its not cluttered and covered with bling.. and is more reliable than some other streaming apps I have used.

Adam Zielinski posted:

Not recognising / not finding streamers on the network may be indicative of some network config issues.

Current verison of the app (5.9 for iOS) has no problems with finding ‘rooms’ almost instantly.

not finding streamers or media servers is almost always a  sign of faulty home network devices - typically wifi access point interfaces to the home router switch back plane not correctly implementing IGMP. One work around on errant devices is to go into settings and disable something called 'IGMP Snooping'. IF you cant see that get a more functional home network router or more capable WLAN access points like from Ubiquiti or other vendors.

Almost nothing to do with Naim - its a bit like complaining your petrol car manufacturer cant really make good cars because it doesn't go well when you put diesel in it.

SimonPeterArnold posted:

The app is plain awful in my opinion. Software is not one of Naims strengths by the looks of things.

Any specific issues that you’ve encountered, so that we can pass it on to Naim?

Using it with my Atom Its very laggy and slow to respond to commands especially when switching inputs or play pausing. Now playing is again slow to update and show changes. Often when connected to the Atom it fails to display anything at all. So a restart is required sometimes two. And lastly it will just  crash too frequently for no apparent reason. 

Bubble upnp super quick, Roon App again super quick and responsive. Naim app hmmm not so and 50/50 if it will work.

Yes I am on Android but I don't buy into this as a viable excuse for poor app performance in this day and age. And yes I am on wired to the Atom, not that having it on wireless makes it any worse either as I have tried. 

My app works perfectly  100% agree all the threads above as to why your app doesn't work.    

You don't give many clues about how your system is set up,  wired, wireless, etc,    I would just start over.  Delete the app, turn everything off & then systematically reboot,  first the router (& let it complete its start process),  then NAS (let it finish),  then the Naim units (one at a time),  then finally re-install the app. & let us know how that worked.    

SimonPeterArnold posted:

Yes I am on Android but I don't buy into this as a viable excuse for poor app performance in this day and age. 

 

It's not an excuse but a fact. It's much more difficult to make an app that works on whatever hardware and whatever version of the operating system someone happens to use, especially as it will then have to operate on whatever home network you happen to have.

The IOS app has always been better than the Android one, but having seen all the email traffic in the beta group about the work on the current release Android app, it wasn't for want of effort on the part of both Naim and the beta testers that it doesn't work for you.

I also find the current IOS release of the Naim app to be very stable and perfectly usable. As I said before, restarting it, which takes a few seconds, sorts out any residual issues.

best

David

David Hendon posted:

It's not an excuse but a fact. It's much more difficult to make an app that works on whatever hardware and whatever version of the operating system someone happens to use, especially as it will then have to operate on whatever home network you happen to have.

I’m still surprised that Naim don’t say “This App is tested on... While it should work on other Android hardware/software such behaviour can be unpredictable and no guarantees can be offered”.

To be fair mines a bit flakey too with my Atom and ipad Pro, perfectly usable but I do have to close and reopen fairly frequently, my wifi is solid and it worked perfectly with my MuSo. The common things that happen are the Radio tab disappears leaving just Artist, Albums and Playlists - this is a regular daily occurrence. Also the artwork on albums vanishes from time to time and the weird one is the source buttons get mixed up as in if I select Tidal for example it will open the radio menu instead! All is sorted by closing and reopening the app. Not the end of the world but a tad annoying. I'm running everything WiFi.

Mercky posted:

To be fair mines a bit flakey too with my Atom and ipad Pro, perfectly usable but I do have to close and reopen fairly frequently, my wifi is solid and it worked perfectly with my MuSo. The common things that happen are the Radio tab disappears leaving just Artist, Albums and Playlists - this is a regular daily occurrence. Also the artwork on albums vanishes from time to time and the weird one is the source buttons get mixed up as in if I select Tidal for example it will open the radio menu instead! All is sorted by closing and reopening the app. Not the end of the world but a tad annoying. I'm running everything WiFi.

Maybe the Atoms the mitigating factor, considering all the other issues with its stability I am facing and others to. I can't compare it to anything else as this is my first Naim product.

I run Muso Qb, Nova and NDX, latest Naim app on Iphone 7 and Ipad 2017 with latest iOS. Once every few weeks I need to restart the app, otherwise it's rock solid. But I basically use it as an interface to UPNP, with occasional Tidal streams. Iradio only gets used when there are test matches being broadcast by the BBC. So I may just not spot the issues others see because I don't use those parts of the app very often.

There are still some silly, and very simple omissions in the app that would substantially reduce the perceived failure rate in the app.

Firstly accept that code that tries to restore existing communication connections is bad practice, even if an attempt at restoration can sometimes be justified as an optimisation in terms of time.

When restoring the connection to the Media Server fails, then an escalating reconnect (i.e. drop and reconnect, not restore connection) sequence is required, and, on success, the screen must be then redrawn to reflect the change in state.  If this fails to re-establish a connection within the maximum time that a slightly impatient user will demand, then control of the reconnect and UI refresh should be handed over to the user.
This is well known good practice, but the Naim app is NOT written to do this.

Evidence:

From my system*

1  When the Naim app fails to reconnect after the Android system is disconnected from the network (typically on recovery from a Sleep state), the Naim app can sometimes be recovered by changing the orientation of the screen.  This just does the screen redraw, indicating a state or race error condition within the app and the control of the UI.

2  A)   When the app is restarted from a suspended state (i.e. restored after swiping off the screen), there is a zero failure rate of establishing a connection to the streamer and Media Server.  That is:  A full reconnect cycle (done by calling the OnRestart() event handler) is 100% reliable.  If unreliability is encountered the app is not doing a full reconnect cycle at that time (i.e. it's trying to take short-cuts).
2  B)   When the app fails to reconnect automatically, switching the connection from UPnP to another input and then back to UPnP and then reorienting the screen to refresh the UI, will often restore the app.  Since we know from 2 A) that a full reconnect is successful 100% of the time, and this sometimes still fails, then this is still not doing a full cycle of drop connection, reconnect and refresh the UI.

Simple answer:  Provide a button for the user to manually initiate a full cycle of drop connection, reconnect and refresh the UI.  Typically this would be done by calling the OnRestart() event handler used on an app restart from the suspended state (rather than calling OnResume() ).

*  Although I can't test it as my system never fails at "Finding Rooms", I suspect the same dodgy approach and resulting failure to reconnect the comms link to the streamer is also the cause of this error.

As far as iOS vs. Android versions of the app goes, Android has always been the poor relation. Naim do in-house development on iOS only, while Android development is subcontracted to a third party. That means new features and fixes generally always come to iOS first, and the subset of features deemed worthy of implementation on Android is then passed to the third party. The result is that Android rarely follows the iOS release cadence, and it has fewer features.

Now, I'm happy that we have an Android app at all. I remember the long period when we just had iOS. However, the way the Andoid version is developed means that it is never as good as the iOS version and is doesn't appear to get the same priority.

The main issues with the Android app now as far as I am concerned are not feature but performance related. I spend far too much time waiting for the app to reconnect to the streamer after waking my phone. Sometimes it will connect, other times I'll see the spinning circle eventually time out and a "You have another client connected" message pop up (which is not the case). This soon gets pretty tedious. I'm patient enough (just!) to deal with it, other users in the house are not.

Huge posted:

Simple answer:  Provide a button for the user to manually initiate a full cycle of drop connection, reconnect and refresh the UI.  Typically this would be done by calling the OnRestart() event handler used on an app restart from the suspended state (rather than calling OnResume() ).

I am not so sure as typically there is no connection as such as the HTTP actions associated with UPnP are connectionless until initiated so there is nothing to drop or restart

Now I can see the IP addresses being problematic where the ARP discovery on some basic home network equipment is not working effectively - so the ARP might not resolve correctly on some network devices (so the ARP cache is out of sync with what the hosts think they are) and therefore requires a low level network timeout to refresh, and so that the IP addresses and network addresses resynchronise and correctly populate the ARP caches.

There should be no real effective change in timing between ARP timeout due to an invalid IP and network address pairing and initiating a manual discovery.. and in practice the former should be a lot quicker as its automatic.

An additional approach is to use the multicast capability for host discovery - which is a broadcast type frame in many home networks - and therefore will go to all ports (assuming IGMP snooping is disabled) and so because the appropriate hosts in the multicast group will respond  then the ARP caches will be maintained - and if IGMP is used for efficiency then the correct port / multicast group mappings are maintained.

So here the challenge is to ensure the discovery broadcast multicast packets are sent out frequently enough, and when IGMP snooping is enabled this becomes more important, and needs to be done is such a way so as not to cause too much overhead and battery drain.

On many home networks this works ok  - but if ARP caches are out of sync with host addresses then delays can occur waiting for refreshes of the caches

Therefore the answer for me is to run an IGMP querier on a managed switch (assuming you don't have a router running IGMP querying) - this is the best way I know of ensuring IGMP and ARP caches for UPnP hosts, servers and control points are always upto date and the Naim app is super responsive each and every time no matter what has changed on your network.

Now all these features are separate to the Naim app...and can be controlled by the network -but if initiated by the app if needed can be slow

Simon,

Yes, from the networking perspective it's a connectionless protocol, but from a software resource perspective there is a connection object that maintains the state of the software connection to the OS networking services.  This equally applies to all the mechanisms you list.

What I'm postulating is the possibility of a software design issue with the functioning and operation of this object rather than a true networking issue (quite probably a timing / thread synchronisation or state management issue, but indeed quite possibly compounded by other actual networking issues).  I'm making this suggestion as I've personally had to fix code with just these design errors, and where the result was patterns of behaviour that are directly analogous to those shown by the Naim app.

I realise I should have been more specific and pointed out that I'm taking a view from the software code looking down the stack rather than from a networking / physical perspective and looking up the stack.  When one gets used to talking jargon it's all too easy to forget that some other people use a similar jargon in but in different context or from a different viewpoint.

To come at this from a user perspective, I think that Huge is right that there should be a way for the user to refresh the app's understanding of what is where. Only the user can know whether the app has found what he/she expected it to find and when faced with an incomplete list of rooms or even "no rooms found", the only course of action open to one is to swipe the app and restart it, which in my experience too always sorts the problem instantly.

So I too have advocated a manual refresh button in the app, although I also suggest it could be called "Go on, have another look for rooms" or "Look again, but look harder this time"!

best

David

How about calling it < JFDI > ?

Doesn't translate well for an international brand! So it probably needs to be something bland like "refresh"....