Android app still not working, need alternative app

Do you know for sure that the Android app is at fault here? Does it work OK with the remote? Have you tried borrowing an iOS device to see if that connects to it?

Believe me its the app's fault. It works with the remote and with an Ios device. And like I said, sometimes it works with Andrord and next day it just won't connect anymore. 

Does the app simply not see the muso sometimes? And when it does see it it will work for as long as you use it but next time it can't find it?

I appreciate this isn’t helping your problem, but I’m suffering from a similar issue where Spotify will drop, and then often the Muso in the ‘other devices found’, has disappeared.

Bananahead posted:

Does the app simply not see the muso sometimes? And when it does see it it will work for as long as you use it but next time it can't find it?

Yes, that's exactly what happens. 

I had this for a long long time, I added a room manually in the app - you need to know the IP of the Muso - and it works 99% perfectly. You do need to assign your Muso a static IP in your router but you can do that after you have tried it in the app for a couple of days..

Hey, also tried this with the manual add and static IP, I guess I'm that 1% where it doesnt works.

But.... I've tried the Hi-Fi Cast + DLNA from the Google store. Works perfectly on all devices. Too bad Naim can't get it to work like this app.

This may sound obvious and you've probably done it, but have you contacted Naim support? I use the Naim App in ios and Android and have been walked through several methods to get it to work acceptably. Support were very helpful, I phoned them a number of times. The method that nailed it for me was to turn everything off including ADSL router, network switch if used and disconnect all LAN cables. Turn on router and leave 5 minutes, turn on switch if used and leave a few minutes, plug in network cables, turn on source's, leave a few minutes to register. There's other walk through's with WiFi. 

Hello, yes I've been in touch with Benelux support several times. Your method I've also tried several times but it only works for short time. After a while the app wont connect to the Muso :-/

Just a thought, have you tried resetting both the Muso and the app to the factory default and starting again? This will, I believe, remove all static IPs.

Done that many times, same result :-( 

Try splitting the bands on your router, it made android devices as reliable as apple on my HH6.

OK, so far I've managed to get the app from not losing connections when I turn off/on the Muso for several times.
But now my NAS (Synology DS216+II ) with all the music is nowhere to be found when I choose the Upnp option.

We're getting there (slowly).....

When the app looses it's connection to the Media Server there is NO WAY to force the app to reconnect.  When the app messes up there is nothing that the user can do other than wait.  The app is written assuming that it's perfect and nothing will go EVER wrong with finding the Media Server.  The programmers believe that they know better than the users.

I've seen this programming style many times before...  THIS IS PROGRAMMING ARROGANCE of the HIGHEST WATER.

All that's needed is a button to allow the user to force a reconnect, it's REALLY SIMPLE; the failure to allow this option to the user is utter crap.

I'm now starting to send feedback to Naim to this effect EACH TIME the app f***s up.  Maybe we can embarrass them into doing something sensible!

I hear what you are saying Huge but have a slightly different take. I've been a programmer for most of my life, and yes, the quality of the app is truly lacking. From a design perspective, a manual reconnect button is low hanging fruit. If the app had better exception handling and internal monitoring, no such button would be necessary as it could rapidly detect a lost connect and attempt to reconnect. It's also easy to sit back and complain without knowing what restrictions Naim work under. If they have done the really common thing and used off-the-shelf third party black box libs, they might be highly restricted (not to mention exposing the device to all manner of other problems). 

Fewer buttons are better but with each button you remove you had better have the backend intelligence to support it so that the loss of a button is never once questioned by the user. A perfect app reads your mind and has no user input interface at all. All apps fail to live up to the ideal.

Clearly design problems were made, but where they were made is less easy to pinpoint without code access. 

Going after the real issue of the internal logic for connection handling is really where some attention is needed and if they cannot do this for some reason like the example mentioned above, then a back-to-drawing-board approach is probably what is called for. But we just don't know. I think it is fair to criticise and say it just doesn't work as robustly as it should. The reasons why could be many.

I have a carefully cultivated network and have never experienced a single connectivity issue in the 4+ years I've had this stuff. That said, the experience of other's does not surprise me. I could list a number of non connectivity based bugs/design flaws with both the iOS and Android app (they are both lacking in different areas). Extrapolating that to a sub-optimal network and I can feel other's frustration. The fundamental UI concept of the app is fine. Shame the execution is more like a 1970's era Jag where nothing works as it should. I find the rule of thumb is always, before listening, kill the app if it was running and open it from scratch. Most bugs seem to manifest after the app has been open for several hours without user input.

Hi FZ, I've been a programmer and then system designer for over 30 years working in complex technical environments (including communications and network applications for both LANs and WANs!).

I'd rather not have a manual reconnect button, but since the coders aren't competent enough to get the auto reconnect system to work (and I've told them their best chance to make this work reliably* but they've ignored the advice), then the last resort is to allow manual intervention.  After having their automatic reconnect process fail and allowing that allowing that failure to persist through many versions over more than two years, then the refusal to accept that their code is flawed and requires manual assistance from the user is the PROGRAMMER ARROGANCE.

*  In my professional life I've seen this sort of code behaviour several times, each time occurring in amateurishly written 'sockets' handling code; each time, the cause has been the same - over optimisation - saving a few seconds in the connection error recovery routine at the expense of reliability.  Someone has had a 'good idea' to make the recovery more efficient,  unfortunately their ambition has exceeded either their ability or their understanding.