Network Bridge - problems with Tidal (again)

Hi, Since Saturday (3 July 2021), i have problems playing Tidal - all music tracks play for 2-3 seconds and then stop for 10-20 seconds.

My system path contains:
Modem -> Asus router -> Ansuz X-TC switch -> DCS Network Bridge -> Metronome AQWO (used as DAC). I use Mosaic App on Ipad.

I have tried all of the following but there is no change to the problem:

  • reset and restart all modems, routers, switch, DCS NB, AQWO
  • Remove Ansuz Switch from the chain
  • delete and reinstall mosaic app
  • change port in modem and router and switch
  • use another device (iphone) to install mosaic app

Just to be clear, i have no problem with all of the followings:

  • play music via USB thumb drive (and mosaic app) on NB
  • play internet radio via mosaic app and NB
  • use the same signal path (from modem to router to switch to TV) to watch netflix or apple tv (HD), which means the internet connection is fine
  • play TIDAL music via tidal app on my iMac, iPad and iphone (meaning no issue with Tidal)

please help.

Noting that you use an i-pad to run Mosaic app I would just remark that there is a recent update to iOS (v. 14.6). Its release notes concern fixing a number of small issues and I have noted improved performance from Mosaic since its installation ( better discovery ).

Have you updated to this version?

Yes, I am using iOS 14.6

Thanks to my friend, he screen-captured the Mosaic app on iPad in January vs July, and he noticed some differences in the display even when playing the same music file - see attached. Is it possible that changes were made in Tidal that caused the Mosaic app or NB to mal-function?

If I am right this is exactly the same problem that you reported in August last year. You did not subsequently post about finding a solution but I assume that the issue just went away only to recur last Saturday.

You say that otherwise everything is working OK playing all other internet sources through the same set up. Only Tidal fails and it only fails via Mosaic.

Faults tend to be consistent until there is a fix. It currently seems you have one that only happens periodically and then goes away. This makes me wonder if something is happening that is completely external to your home system. Tidal via Mosaic is somewhat different to Tidal playing via its own app running on a computer or phone. With Mosaic I understand that it relies on the services provided by airable along with all of the internet radio stations. Those radio stations tend to be lossy but you say are working OK ( I am assuming that when you say internet radio is OK you mean internet radio via Mosaic ?). So the issue seems to be unique to Tidal playing via this source and to you in HK ( as nobody else is reporting anything similar).

Are there any other Hong Kongers experiencing this? I think that there may be other contributors to this forum from HK and it would be helpful to hear from them.

Your screen shots were posted whilst I was writing my post above so I have only just seen them.

The main thing I see is that the file playing in July is not the same as the one in January. The January file is lossy MPEG but the July one is a Tidal Masters MQA encoded one. However you say that ALL Tidal files are currently stopping after a few seconds playing. Is that correct?

NB: As explained last year as you do not have a dCS DAC you will not be able to replay this MQA file at its fullest resolution.

Thanks. The issue last year was not fixed but bearable. it happened sparsely. at least it plays the whole track uninterrupted.

Now I cannot even get through 5 seconds of music without stoppage. it applies to ALL files… So in my mind this is a different issue

To answer your question, internet radio via mosaic was fine.

Thanks for the clarification. So the problem did not go away it just happened less frequently.

One thing has changed with Tidal since last summer. They have greatly expanded the catalogue of MQA encoded albums. Is there a problem with your setup and MQA as this may be an explanation of why everything but Tidal works OK? Have you fortuitously been selecting non MQA encoded albums in the meantime ( including when using Tidal’s own app) such as the example of Mozart concerto in January but , due to Tidal’s MQA expansion, are now finding all MQA albums perhaps without noticing?

I have the same problem with both MQA and CD albums/tracks in Tidal, so it has nothing to do with its MQA’s expansion…

Well, I am now stumped for an explanation.

Simon, it’s not uncommon that when you use Mosaic/Tidal, music is streamed from a different Global cache provider than when you use Tidal’s native PC/Mac App by itself. So, the former could fail, while the latter seems to work just fine.

In which case the problem is within your Internet Service Provider’s domain, rather than inside your house or your dCS Network Bridge as such.

Have a read of the following post and maybe try the suggested diagnosis, it might lead to additional insights into the problem you’re facing;

1 Like

THank you for the detailed info. this is very helpful.

I tried the ping tests for the 3 servers. It turns out that for Akamai, i got this response
ping: cannot resolve Unknown host

for Fastly, I got 40% packet loss a few times (but ok at other times but at a slower speed around 224ms)

cloudfront is generally ok at 3-5ms.

What should I ask my ISP to do?

That’s a good confirmation. Pretty much exactly the kind of results I would have expected based on the symptoms you outlined in your first post. :+1:t2:

Mosaic/Tidal does seem to always use Fastly caches. While Tidal by itself uses CloudFront (you can ignore the Akamai ping failure, I suspect Tidal no longer uses them as a cache supplier).

The problem may not be entirely due to your ISP. Fastly recently had a major global outage, things may not have quite settled in some parts.

That said, and before you speak to your ISP, you might want to try a couple of things. Maybe start off by pointing your DNS elsewhere; on your Network Bridge under the “Network Settings” page, override your DNS to Google’s ( and CloudFlare (

Let’s see if that helps. And if not, we might need to trace exactly where your nearest Fastly cashe really is. Where are you located geographically (which country I mean) if you don’t mind my asking?


Thank you! I will try this tonight when I get home. I actually tried using VPN on my iPad with Mosaic yesterday but it didn’t help at all.

I live in Hong Kong.

just did it to override DNS to google and cloudfare…

the problem remains… :cold_sweat:

That won’t work unfortunately. The Mosaic App is only a “control-point”. Once you select an album/track, your dCS Network Bridge will go out and pull the stream directly from the source/cache. Music streams do not flow through the Mosaic App.

Fastly actually has a point-of-presence in Hong Kong. So, under normal conditions, you should not be getting occasional 40% packet loss with 224ms ping response times!

OK :thinking:

Let’s try and locate the Fastly cache that your ISP’s DNS resolves, here’s how; from your PC/Mac - I’m assuming it’s connected to the same network as your dCS Network Bridge - get to a command line and issue the command;


It should return something like;

Non-authoritative answer: canonical name =

In my case, that is a Fastly cache in the U.S.

Take the address that you get and type it into to see where that address is physically located. With that information, we can maybe figure out what your next steps might be (likely for you to chat with your ISP :wink:).

1 Like

Thank you. Yes the server is physically located in Hong Kong.

Simon, I established a VPN to Hong Kong and tested that same Fastly cache, it works fine. So, Fastly (HK) is not the problem.

Assuming all your other Internet applications (your home) are actually working fine, then it’s likely your ISP has a problem with their Internet Exchange point, and specifically to Fastly’s Servers in HK.

Here’s my suggestion;

  1. Double confirm - like what I’ve done above - that you’re getting high packet loss % and ping times in the 200s of milliseconds to that Fastly cache in HK.

  2. Take a screenshot of that and email your ISP Support help desk; let them know that your application to that server is failing because of the occasional high packet-loss and high latency.

Ideally, packet-loss should be 0% or single digit % worst case, and ping round-trip-delay should be in 10s of milliseconds.

Hopefully we’re not missing something else :laughing:… Good luck! :crossed_fingers:t2:


This isn’t something I’m having a problem with (though I sympathise, Sims!), but I just wanted to say how much I value your help on network stuff like this, Anup. You are an absolute star.

Anyway, back to the tunes and a beer in the sunshine :slight_smile:

1 Like

Thank you again for you help Anup!

I retested again just now - there were no packet losses but the latencies are still at 220+ ms…

I will call the ISP and see what they can do

Thank you again and will keep you posted!