Internet radio drop-outs - recent problem [Solved - ISP Issue]

Core Machine (Operating system/System info/Roon build number)

QNAP TS-473

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

TP-LINK VR2800 Router
Netgear Gigabit Switch
CAT 5E Cabling throughout

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

Example end-point (but same happens on Sonos end-points too):

Pro-Ject Stream Box S2 Ultra
Pro-Ject Pre Box S2 Digital

Description Of Issue

I THINK this issue is ISP related as I am seeing other performance issues with internet access, but I’m hoping replies here could help me to confirm that I’m barking up the right tree so to speak…

Internet Radio has always been stable, but in the last few days has been very inconsistent. Several channels on several end-points will play for a random number of minutes, then simply stop. Sometimes I see a “Roon has lost control…” message if I happen to be looking at my screen at the time. Playing files from my library (including Tidal) seems to be working fine.

My ISP (British Telecom) are saying they have no faults or issues on the WAN, my TP-LINK router isn’t reporting any drop-outs or issues so I am at a bit of a loss and am hoping someone here can give me some suggestions of things to try, or at least help me confirm that it is an ISP / WAN problem.

Playing the same Internet stations directly via the Sonos app behaves the same way, but Roon at least gives me access to some detailed logs!

I snapped this from the logs when it happened just now:

07/19 11:28:22 Info: [Daves Room Stream-Box-s2-Ultra] [zoneplayer] Playing: channel://icy%3a%2f%2fbbcmedia.ic.llnwd.net%2fstream%2fbbcmedia_radio4fm_mf_p%3fs%3d1563524519%26e%3d1563538919%26h%3d7c751eaa797708f51613d96e8d3dbc32
07/19 11:28:22 Trace: [Pro-Ject Audio Systems Stream Box S2 ultra @ 192.168.1.100:41035] [raatclient] GOT [11] {"status":"OutputMessage","message":{"signal_path":[{"method":"usb","type":"output","quality":"lossless"}]}}
07/19 11:28:22 Trace: [Pro-Ject Audio Systems Stream Box S2 ultra @ 192.168.1.100:41035] [raatclient] GOT [11] {"status":"OutputMessage","message":{"signal_path":[{"method":"usb","type":"output","quality":"lossless"}]}}
07/19 11:28:24 Info: [Daves Room Stream-Box-s2-Ultra] [zoneplayer]     Open Result (Playing):Result[Status=Success]
07/19 11:28:24 Info: [Daves Room Stream-Box-s2-Ultra] [zoneplayer] Aborting play because track changed
07/19 11:28:24 Warn: [streammediafile] error reading stream: Unable to read data from the transport connection: interrupted.
07/19 11:28:24 Info: [audio/env] [zoneplayer] All streams were disposed
07/19 11:28:35 Trace: [roonapi] [apiclient 192.168.1.108:43716] CONTINUE Changed {"message":"Running (855)","is_error":false}
07/19 11:28:35 Info: [stats] 2695mb Virtual, 574mb Physical, 283mb Managed, 0 Handles, 62 Threads

ANY feedback, help or tips on how to debug would be gratefully received as I’m not sure where to go next!

Thanks.

Hi @Dave_Kitson,

Can you please share the streaming link to a few of these problematic stations and how long it usually plays for?

Since this behavior also occurs on the Sonos app, I am inclined to agree that this looks like network instability, where the connection to the stream is lost and playback stops.

Are both your Sonos devices and Pro-Ject endpoints connected to the same switch? If you try to bypass the switch and connect directly to the router, does the same issue occur?

Does the same behavior occur for local zones that are not on the network but rather connected to the Core? E.g. Does this behavior occur for “System Output” as well?

How are your DNS servers set up? I can’t guarantee this will help, but if your ISP is having DNS issues you may want to try switching your DNS servers on the router level to Google DNS or Cloudflare DNS.

Hi @noris,

It never even ocurred to me that it could be a DNS problem. I’ve configured the router to use the Google DNS servers as you suggested and started a couple of radio streams.

At the time of writing, both streams have playing fine for 20 minutes and some of my other issues seem to have gone away!

I’ll continue to monitor and update this thread later - but fingers crossed you may have nailed it!

1 Like

Ok - I spoke too soon - both channels dropped. multiple times…

Here’s the replies to your questions @noris:

Can you please share the streaming link to a few of these problematic stations and how long it usually plays for?

http://opml.radiotime.com/Tune.ashx?id=s25419&formats=mp3,aac

http://opml.radiotime.com/Tune.ashx?id=s24943&formats=mp3,aac

Both (and others) play for random time before dropping, anything from 1 to 40 minutes - i can’t see any pattern.

Are both your Sonos devices and Pro-Ject endpoints connected to the same switch? If you try to bypass the switch and connect directly to the router, does the same issue occur?

This is quite tricky for me to test given the physical location of everything (router is high on the wall in the hallway, switch is in a cabinet in my office and the endpoint is connected to a network port) . What I do know however is that I can stream music from my NAS through the switch and that network performance in general is perfect. That said, the Sonos Bridge is attached directly to the router - so that effectively bypasses the switch!

Does the same behavior occur for local zones that are not on the network but rather connected to the Core? E.g. Does this behavior occur for “System Output” as well?

The core runs on a NAS - so I don’t have any local zones that bypass the network to test.

Thanks again.

Hi @Dave_Kitson,

I tried to play the first station BBC Radio 4 on my end and it has been playing as expected for the last 3 hours. I will give the second one a try as well, but I don’t expect this to be different than the previous link.

You may not have anything connected to it, but the NAS should still offer a “System Output” zone. Even if you don’t physically hear anything coming out of it, if you start playback on this zone, does it stop after 1-40 min?

Can you let me know the exact local time + date when this behavior next occurs on your Sonos zone? E.g. 3:50PM on 7/22/19? I can take a look at diagnostics from your Core to see if there are any other clues. I know you posted a log snippet in the first post, but it doesn’t show all the surrounding info as to what happened immediately before/after that log snippet.

Hi @noris,

Apologies for the delay in replying - I have been trying all sorts of things to remedy these issues I’ve been having. I replaced the router and a few hours ago, I even replaced the British Telecom socket that brings my WAN connection into the house (I opened it up and saw that it was damaged and wondered if the built-in VDSL filter was damaged so replaced it. It just looked suspect). Since doing that, so far at least, I’ve seen a vast improvement when browsing web pages, far less failures, however I’m still having problems with Internet Radio.

I took your advice and have tried playing a couple of channels to the System Output of my NAS (which it transpires does have a rudimentary sound card in it)! Unfortunately the same problem persists on the NAS, my Roon Ready endpoint and a Sonos end-point.

An example can be found at 23:20 on 7/28/19 in the server logs. Do I need to send you those logs or attach them somewhere?

Thanks,
Dave

Hi @Dave_Kitson,

Thanks for checking those aspects and for giving System Output a try. Since System Output displays the same behavior, we have narrowed down the issue to either the Network or the Core itself.

No need to send them, I have activated diagnostics mode on your Core and what this action does is automatically generate and upload a log set to our servers for analysis.

I am looking through the logs now and I can see quite a few Network-related issues and it appears that Roon stopped receiving internet radio data at the timestamp you mentioned. This still appears to be networking-related, but this still does not fully rule out the Core as a possible cause. Let’s try a follow-up test here to rule out the Core machine.

Would you by any chance have another PC around the house which can run Roon? If so, can you create a Backup of your current Roon database and then host the Roon Core on the other PC and make sure to have the same network connection as the QNAP (same Ethernet cable/same switch)?

This would help separate the issue down further and I believe it would be a useful data point to have.

Hi @noris,

I tried two new things:

  1. Running a known-to-be-good cable directly from the router to the NAS hosting the core and played two radio stations to the system output, and

  2. As per your suggestion I installed a new core on this PC, restored a backup taken from the orginal core on the NAS and tried two stations played to the PC’s system output.

In all cases the stream only played for a couple of minutes (or less) and dropped.

As I am having no issues streaming hi-res files stored on the NAS, I assume the issue is with the ISP / WAN rather than my network, but that is confusing as things like Netflix, streaming MQA files from Tidal etc are working fine. Is it possible or likely that my ISP are having problems with just certain protocols or file types or something?

Another interesting observation I made today is that playing one of the problematic stations using the Sonos app (so not using Roon at all) still has the dropouts, but it seems to recover itself after a few seconds and start playing again. I guess this is due to the time / number of retries that Sonos makes as opposed to Roon(?)

Hi @Dave_Kitson,

Thanks for confirming that the issue occurs on a different PC as well. Since we have eliminated the hardware aspect, all that is left in the equation is the networking side of things.

It is possible that this is the case, yes. Netflix and TIDAL use different buffer sizes for their streaming strategies. Since Roon is performing on-the-fly streaming and data processing (and in higher resolution), a stable network connection is a requirement and much more important in this case.

Since Sonos also had the dropouts issue with the native app, this further confirms the networking side of things.

We can try to confirm further if this is the case and then request your ISP to review your connection setup.

We can attempt to confirm this by perform a ping test to the external network address and verify if packets are being dropped. I have looked up the streaming URL server from the opml.radiotime BBC link and have found that the servers they use are bbcmedia.ic.llnwd.net

The steps to perform this test would be to open command prompt on the Windows PC and type ping -t bbcmedia.ic.llnwd.net and this command will send a continuous stream of pings to BBC’s streaming servers. You can exit this test at any time by pressing Control + C but I would let it run for some time (the average amount of time until the stream typically drops).

If you start seeing “Network Connection Timed Out” messages or increasing lost amount of packets, we have found the issue, and I would discuss these results with your ISP. You can also likely perform a ping test from the router itself (if it supports such a feature) and ping other servers such as google.com to establish a pattern to present your case.

Thanks again for your reply @noris.

There have been developments! Yesterday I eventually managed to persuade British Telecom to send an engineer and he arrived here at about 10:30am this morning. He tested everything and whilst he couldn’t detect any significant problems, he decided to replace a lot of hardware and cable where the WAN enters my building and made several trips to their cabinet and switched me to a different port. He didn’t finish until 16:30 so he was obviously pretty thorough!

I hope I’m not being premature, but I started a stream 2 hours and 49 minutes ago and it hasn’t dropped once. We’ve had other streams running in other rooms on and off at the same time and so far everything is working perfectly.

So, hopefully I’m not tempting fate by typing this but it appears that it was a network issue, and it’s now resolved!

Many thanks for your help - the feedback on here gave me confidence to keep arguing with the ISP who were insisting there was no issue.

With a bit of luck - we can call this fixed.

1 Like

Hi @Dave_Kitson,

Thanks for the update here and glad to hear that the ISP engineers were able to review the wiring for your install and make changes!

I believe we narrowed it down significantly and have correctly determined the issue so I will go ahead and mark this thread as [solved] :slight_smile:

If you experience further issues down the line, don’t hesitate to reach out to us again. Thanks!

1 Like

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.