To be fair 99% of situations are network related when it comes to discovery, but it should not be the default response from others that don’t have any idea about a) how the other person’s network is configured, b) what expertise and knowledge the user already have in this area, and c) jump to the conclusion that it works for them therefore it must be ok and it’s the other person’s hardware.
1 Like
I even accept that there might be the occasional issue that affects only one app and occurs even on a network that looks healthy. I know from my work - we have millions of machines running our software, but some issues occur just on one.
So I contacted support and the first response was “it’s your network”. When i investigate a problem for our software I usually prefer to have a look myself on affected machines, so I offered the Naim support basically full access. Then they had me do a network scan from the Naim app, but nothing was found.
Yep, that’s the standard response. Funny how all other apps work on the same network in the same location on the same device. I can control the heating, lighting, smart meters e.t.c all on the iPad without a hitch and then switch to the Naim app and nowt, nada, just tedious restarts. Yep, sounds like the network to me!
And I want to add that Naim is responsive and we are looking into it in the beta team. They also quickly fixed some things in the app for the next version that I reported.
I am just getting riled up, sorry, that every time there is a thread attempted by customers to get to the bottom of some issues that obviously exist for some, and to collect UI issues in particular on Android, which also clearly exist, it is derailed by someone showing up to say that all is fine, what do you want, and iOS works anyway.
It’s uselessly disruptive to honest efforts to help Naim improve, and while it is good that Naim is loved so much, this attitude is the opposite of Naim’s own, which is very much not “it’s fine”.
2 Likes
Unresponsive is not something I recognise. And yes I have to agree judging by the numbers of complainers on the forum that something isn’t right. But what’s caused the problem(s) is hard to imagine when you don’t have the problem yourself or have a problem app in your hand…
If we were not in this damn lockdown I would suggest to join up with people in a reasonably local travel area to compare apps in different setups, networks & ISP hubs.
1 Like
And to a degree this is helpful to know. In my case, it was helpful to me to get further confirmation in this thread that I am not alone with this, and also that it works for others with other tablets, including other Samsung. Both together completes the data.
But I think we are all aware that for the vast majority of iOS users things are better (but not for all, like matfff, which is also interesting).
Getting this info from others and making comparisons is not a bad first step to understanding the problem,in particular as we cannot meet up. Like I said, I had a reasonable suspicion that Qobuz login has an effect, so being able to ask others if they can confirm, that’s super helpful.
Getting such info is harder if there are every time ten iOS users who not only say “works here” (though yeah, we know! 
) but start a whole different discussion.
I started out with the app and was disappointed with it’s library functionalities, so i tried out Roon but was disappointed with it’s lack of UPNP support, so now i’m back on the app and only use it as a simple UPNP remote. It works fine in that regard (for me), but yes, it would be nice if it were as convenient and feature complete as the marketing and reviews suggest…
Qobuz may be at the heart of the problem with unresponsiveness: I logged out of Qobuz and deactivated the input, and all of the unresponsiveness disappeared! Even when I activated the input (but did not login) the unresponsiveness stayed away.
As soon as I logged on to Qobuz again, the unresponsiveness came back. I think I noticed a few moments where it grew from none to standard but that was quite quick. And now it seems worse then ever… But that seems to be due to a discovery process for Qobuz: some of my presets (those that were albums in Qobuz) were gone. Now that they are back unresponsiveness seem to be back to standard.
It looks like being connected to Qobuz does play a role in the unresponsiveness on Android.
Can IOS users with connections to Qobuz please do the same test?
–Jan
Well said. I’m on Android too, and the Naim app definitely has its set of problems, bugs and usability issues. As a counter-example to “it’s the network, stupid” (example when connected to my Star): go to Servers → Local music → Artists then pick an artist and wait a ridiculously long time for the contents to show. The same thing in e.g. VLC is much, much faster.
[And it’s not caching either, as it doesn’t matter whether I pick that artist first in VLC (from the Star as UPnP server), then in the Naim app, or the other way around.]
1 Like
I’ve flagged this thread up to Naim app team, in particular the Qobuz issue
Wow, many thanks, sounds exactly like me. I could at first repro immediately: log out of Qobuz - responsive. Log back in - unresponsive. Several times. Then I stayed logged out and it was still fine the next day. I thought I had it and reported in the beta thread. And then a few days later (as I usually use Roon) I tried again and the unresponsiveness was back although still logged out of Qobuz. I also thought “worse than ever”. I reported this too a few days ago and since then have not been able to make progress.
Great to read your results, really. I’ll keep digging
Edit: I have to add:
I cannot confirm this one: I have no Presets (had them all deleted already before I played around with the Qobuz thing) and it makes not difference for me
Thanks, I did report it to the beta team already a few days ago. It’s just not clear still (see my post right above this), so LJS’s results are very helpful
Only used Android app and just for UPnp/iRadio/input switching (no other services). Two (old platform) devices which generally change between each other pretty well.
Do quite often get a ‘hang’ when coming back into the app (e.g. when playing a uUnP track, doing something else on phone and coming back to see what the current track is, etc.).
Generally happy with the app. Two things I’d really like it to do:
Use hardware volume buttons to control device volume
Use notification pane in Android so you can see what is playing and possibly pause/play, etc.
These two suggestions (particularly the first) have been around for a long time and, while I do accept the ‘Android is fragmented’ argument to some extent things really have moved on in that score in the last few years. Many other apps (and not just large-firm apps like Sonos or specialist indies like Bubble UPnP) seem to be able to do this sort of thing without too much trouble.
1 Like
What is your Naim unit? Hardware buttons on mobile work for me (controlling the NDX2 volume via app, which uses system automation to control the NAC. And, which is extra nice, this even works when the music plays through Roon, as long as I have the Naim app in the foreground on the tablet)
Edit: And you need the setting as litemotiv says in the next post
Thanks, another one 
Could you tell me your device and Android version? I am going to compile them up and provide to Naim
Options > Other Settings > Use Hardware Buttons For Volume
It works! I think I’d stopped looking at this ages ago and not noticed this addition!
UnitiQute (1) 192 version / Mu-So Qb (1) / Android 10 [oneplus 7 plus]
1 Like
The fact that two people, both using an iPhone, both using an NDX2 (or whatever) so both using exactly the same hardware running get same IOS and same firmware on the hardware, have different experiences can only be down to one thing: network.
They maybe even use the same kind of network - for example a BT Homehub.
BUT, there is clearly something in the implementation that differs, be it interference from a neighbour, a Microwave oven, proximity of a cordless phone of fluorescent lamp but, SOMETHING is causing an issue.
I have two totally seperate systems in seperate homes, both have different networks, one using a ISP router modem, one using a pro-grade Ruckus system.
Both of my NDX2 work perfectly and the app rarely, if ever needs re-booting or anything.
Although clearly some folk do have issues with “looking for rooms” or whatever, I cannot believe it is all down to their hardware or, the app.
As I say, if the app or streamer is broken, why does my app always work?
The only difference I can possibly see is the network. (or music server on a NAS)
If anyone is having problems, bring their kit to my place and try it on my network. If it works, you’ll know the answer…
I should add, I don’t use Android devices.
1 Like
That’s not necessarily true, it can be due to anything in the code of the app as well. Specific settings enabled/disabled, being logged in to certain services, multiroom environments, USB being used or not etc.
It would be the wrong approach to state that even if the network plays a role, it’s therefore the user’s fault and the network should be changed. It could very well be poor code in the app that is unable to properly work with certain network setups. Most network devices are a lot more standard and prevalent than Naim gear, so it would be reasonable to say that Naim needs to adapt to the norm, and not the other way around.
As was mentioned earlier in the thread, many of the people who do experience connection problems with the Naim app (i personally don’t), have for instance no issues with comparable apps from other vendors like Bluesound, NAD etc.
4 Likes
To all, the app team are aware of this thread and at least one possible unresponsiveness cause on Android is already being addressed 
My thanks to everyone who already posted their device details and test results, please carry on