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.
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.