One of my suggestions has been that it doesn’t display a reconnecting message for the first couple of seconds and then if it takes longer than a couple of seconds it displays a “Reconnecting to device” message (which is positive) rather than “Lost device, looking for it again” message which is negative…
1 Like
Ahh, Newspeak 
New mosaic versions seems to have cured this issue for me, no more lost connection anymore when picking up my Ipad 
Hopefully it stays like this
4 Likes
@imprezap2 I’m getting a lot more ‘Lost Connection’ messages from Mosaic. I could be wrong but it seems I’m getting more since the Apex upgrade on my Rossini.
My versions as reported in the Mosaic Support → Versions page are:
App Version: 1.4.0 (143)
Front Panel: 2.04
Control Board Version: 2.04
Network Board version: 1.3.0 (509)
I seem to be current as I just checked for updates.
To dCS Support, any ideas that you can recommend.
Thanks,
Brian …
dCS Support, I’d like to add that most of the Mosaic ‘Lost Connection’ messages I get are the result of trying to add Qobuz tracks/albums to the queue.
Brian …
Brian, as you are probably aware quite a few of us have been experiencing lost connection issues with Mosaic v1.4 and several are reported in this thread earlier. I have sent a few reports on this as they have occurred directly to Phil as he requested at [email protected]. So it may worthwhile your doing this as well so that Phil knows without having to trawl through the forum postings.
I still have the lost connection issues, but the frequency seems to be less after the last Mosaic update.
It’s annoying, but it seems to belong to the way dCS have designed the app.
Just to try to complete the circle on this one.
Regarding the opening posting - the APEX update consists of a replacement DAC board for the Rossini and Vivaldi. The original hardware for control and network remain untouched and the firmware / software is exactly the same pre and post APEX update so the APEX update itself cannot create network discovery issues.
The 1.4 Mosaic release added in the function to be able to directly specify an IP address for a dCS device to connect to on your network but please be very aware that this is not a “fix” for anything - if you do use this function then it is a workaround for an underlying network issue (in that UPnP autodiscovery isn’t “working” on your network for some reason) and ideally that issue should be identified and resolved.
It (the 1.4 Mosaic release) introduced no changes into the way that the app discovers network devices - the discovery method remains the same (there was a small change for Android as Android 13 depreciated a couple of network functions that existed in Android 12) and all network discovery is performed through fully documented and well tested functions provided by iOS and Android - so no, we don’t just “wing it” and do our own thing, doing so would ensure that the Mosaic app would be rejected by the automated validation processes that all apps go through when submitted to either the Apple AppStore or the Google Play Store …
As such, neither Mosaic nor dCS hardware require anything special in the way of network functionality which is why it is difficult when people ask what they need to check is supported when looking for a new router or switch etc. - it just needs to work correctly and reliably - which is where a lot of consumer level network kit kind of falls over.
In a previous life I (and some others that I worked with at the time) did a lot of testing on a bunch of ISP supplied routers and were able to show that over a period of time some would become less able to handle UDP traffic and would simply discard UDP data. A reboot would resolve the issue for a while but it would eventually return. This is something that we (or any other manufacturer that relies on a network) cannot “fix” - we can’t do anything to affect the underlying network. I was also involved in some testing on home mesh network devices a couple of years for a client where we evaluated a sizeable group of mesh capable routers and extenders and if all you were doing was getting computers and TVs onto the internet then they were fine but as soon as you started to throw more complex devices (such as SkyQ Mini boxes) into the mix then we started to see random connectivity issues.
A reliable router doesn’t need to be expensive either - I’ve recently been using a £14 Huawei cable router in a little test setup here and it’s been absolutely reliable so far.
6 Likes
Phil
As you know we’ve been emailing about the continuing issues I too have with Mosaic and Qobuz disconnects. While it seems to be a Router issue somewhere, and mine is one of the most popular tp-link routers, please appreciate the user frustration that this causes. It completely ruins the user/listening experience. Also, given that there are other solutions that work completely reliably can DCS not try a different architecture approach to fall i line with others? In my case, Linn Kazoo with bubble upnp on my PC works perfectly, and I’ve just had an Aurender n20 on loan which also works faultlessly via their Conductor app. I don’t fully understand all the technologies involved but when I try solutions that work and meet my user expectations, then to me it proves there is no fault with my router or set-up. Why can’t you copy what Linn, Aurender, and Spotify, to name a few, have done in their “technology solution”? Many thanks for your consideration at least.
1 Like
Always easy to blame an underlying network problem, but with my Aurender N10 there is no problem.
I have had a simular issue with Viaplay (streaming F1 races), many times last year the picture quality was below par, when bringing this up to Viaplay (many people did) the first reaction is to look at the network, but my Netflix stream is very reliable at a higher resolution and bitrate, so it should not be the network.
Over the year the Viaplay picture quality got better, and I did not change anything in my network.
Anyway, Personally I don’t consider the “lost connection” a big issue.
Coming back to this thread after a while it seems to me that nothing is being done about what is a common issue and the dCS team seem to be in kind of denial that it is a real issue. Why is that? Some of the responses feel like we users are thought of as just being a bit impatient! I’m not technically capable of understanding the ins and outs of why the problem exists. I just know it is tremendously irritating and not something I have experienced using other apps with different manufacturers’ equipment, so having ‘upgraded’ to dCS from Naim I love the sound improvement but I really am not loving the UI issues. I very regularly get a ‘lost connection’ message and turning that off is NOT a solution for me - I will still notice it. About one in ten times it doesn’t reconnect at all and I have to take more drastic action, like powering down and up again. If I want to listen to some music I don’t want the tech to get in the way - I want it to facilitate a good listening experience.
3 Likes
Nick I agree with your wish for a problem free experience with Mosaic. In fact I am one who has complained in these threads about connectivity issues. However I think that Phil gave a good explanation of the issue a few postings above and that these are intrinsically linked to the way certain networks ( e.g. routers) are configured . They work OK ,however ,for simple devices in control app terms.
I note your reference to the Naim app. Please be aware that despite what seems to be your fortuitous experiences with the Naim app in use it appears to suffer from pretty much the same issues as Mosaic. As am no longer a Naim customer ( great company for whom I have a lot of respect) I simply googled “Naim app connection” and was directed to numerous issues which look pretty much the same as here. In fact so prevalent are they that Naim have put up a troubleshooter page of which the contents will seem familiar to any regular posters here.
I am no tech and cannot meaningfully go into that area but it seems that the unilateral actions of third parties have implications for users such as dCS which are unpredictable and provide continual headaches. The same goes for the providers of the platforms upon which apps work . I have found more than a couple of companies who once provided apps for their products who have had to abandon the entire business as they could no longer afford to implement the changes demanded regularly and without notice.
1 Like
Helpful thoughts Pete. Thank you.
I had a very good experience with Naim with my main system although I did have connectivity issues with a the Muso I had for a few years. I just think that technical guys (I’m talking generally not dCS specific at all) often fail to engage properly with the user to see how their tech works for how they want to use it and it is a constant frustration of mine - currently with my iPhone operated skylight!
Hi Simon (and everyone else),
Most Android and iOS apps are developed using a common pool of development tools and the same validated and verified Android / iOS function libraries so it is extremely likely that our app developers are using exactly the same set of operating system calls to do network discovery that everyone else is using (so that they comply with the validation requirements for the two main app stores) and if you go browsing any of the forums for any of those products / manufacturers that you have mentioned then you will find a similar small subset of users with similar gripes and grumbles.
We have a very well defined process for the app discovering / connecting to and reconnecting to devices and that works very effectively in most situations … the app will try to connect to the device it was last connected to by its IP address first (as that is the quickest route), if the device isn’t reached at its IP address (which could be due to the device changing IP address on a DHCP based network) then it will broadcast a UDP message to the device, if there is no response to the UDP broadcast then the app falls back to the main device selection screen after doing a search for all the devices on the network.
If there is an issue in the app reaching the device across the network then we are unable to do anything about that - the underlying transport between network devices is something that we can’t “see” or “test” or “validate” or “fix” … if a TCP/IP packet that is sent out to a specific devices IP address doesn’t reach that device due to an incorrect routing value in a switches routing table then we cannot do anything about that, if a UDP broadcast reaches some parts of a network but not other parts then again there is not a lot we can do in that instance until the underlying network sorts itself out.
If a network is functioning correctly then TCP/IP packets are routed correctly and UDP broadcasts do reach all destinations and everything works correctly and as intended and in that case typically the app will reconnect to either of the two dCS devices that I have here within two seconds of the app screen opening no matter whether on Android or iOS.
At the risk of oversimplification (!) you can think of a network a bit like The Post Office / Postal Service … if a device on the network sends out a TCP packet of data intended for a specific recipient - a letter as it were - that letter has an address on it (the destination IP address) of where it is supposed to go. Each network switch on your network maintains a basic routing table within its memory, a bit like a local postal sorting office would know which post bags to put letters in that are destined for different areas, of what device addresses are connected to each of its ports … each ports “list” can have many addresses attached to it (the equivalent of those postal bags where the letters for lots of different addresses go into) and the switch doesn’t know exactly where the device is downstream of that port but it knows that it is somewhere down there so it sends the data out of that port (that postal bag) to be passed on by whatever is attached to that port (the next sorting office) rather than flooding the whole network and sending it out of every port (the equivalent of making a copy of it and putting a copy of it in every bag) … now this is something that the network itself handles and manages with its own internal housekeeping (all this is part of something called the OSI model which, like Dante’s inferno, has multiple layers of hell and is possibly something to Google when you really can’t sleep), it is (generally) outside the influence of any regular client devices that are attached to the network and sometimes a devices routing tables can simply (for whatever reason) be wrong/invalid and packets of data end up at the wrong address and don’t get read and actioned - a bit like if you receive an incorrectly delivered Xmas card for someone that isn’t anywhere around you, you wouldn’t open it, you might throw it back in the post and hope that the post office eventually get it to where it should be but you wouldn’t really go out of your way to deliver it yourself and make sure that it was received.
Network broadcasts are used for device discovery. A UDP network broadcast is handled differently - more like a junk mail circular - in that the flyer (packet of data) gets sent out by the company offering whatever service, window cleaning perhaps (or an app asking what devices are on the network), the sorting office puts a copy of that flyer into everyones post bag and sends it on with the aim that everyone eventually gets a copy and those people that are interested in having their windows cleaned (or the devices that are being looked for) will reply back directly with everyone else ignoring the flyer - the thing is sometimes the sorting office makes a mistake, they drop a bunch of flyers, they forget to put them in a postal bag for forwarding or the postman doesn’t like the street or for whatever reason the flyer doesn’t get delivered and so the customer doesn’t know that someone could wash their windows for them or the device doesn’t know someone is looking for it.
Now, all this stuff SHOULD work properly and generally does work properly - it just occasionally doesn’t - and that’s generally why these sorts of problems occur. Commercial (or corporate) networks have much better resiliency and underlying management built into them to ensure that these kinds of issues don’t exist but in consumer grade kit the resiliency and management is side-lined somewhat in the interests of ease of installation and, of course, cost.
So, I do understand that “unspecified random network issues” can be incredibly frustrating and seem like a copout on my/our behalf but at the moment here at home I am unable to SSH into one of my keyboard and monitor-less Linux machines using the machines network name from one of my laptops (although I can using its IP address) but I can do so using its network name from several other laptops and that is annoying too - but I know that at some point the cached name tables will update on that machine and once again it will work the way that it should, and I’ve just had notification that the smart switch that controls our pond pump has gone offline but the smart switch that controls our garden lighting and sits 10cm to the left of the pond pump switch is chattering away to my network just fine - but these kinds of things can just occur.
BR
Phil
2 Likes
Hi Pete,
chuckle
I think I wrote much of what’s in that while I was there but it’s nice to see that they compiled it into a single page… 
The most useful part of that IMO would be the following…
" The simplest network [for any system] is to have the product directly wired into a single wireless router and the app connected wirelessly to the same router and within close proximity, with no other devices connected. If this works with your equipment, then start building the network back up by adding any additional devices or equipment slowly until the undesired behaviour begins. You should then look specifically at that change to see If that’s what caused the issue."
Unfortunately, quite often the “undesired behaviour” won’t start for some time after bringing up a network or making a change as often network issues need to accumulate and snowball or network traffic has to reach a tipping point before they actually start to cause problems.
But yes, issues and oddities caused by the vagaries of domestic networks are not in any way unique to dCS products and certainly when I was there there were exactly the same things raised and I’ve had the same conversations over the years regarding numerous other manufacturers kit too …
ATB
Phil
2 Likes