Rossini endpoint not aways visable

My simple network based on Fibre to the Premises (FTTP) then Ethernet with cat 5e cabling.
Sky Router model SR203
Netgear GS734T 24 port (unmanaged, fanless) switch - Ethernet
Synology DS218 NAS - Ethernet
dCS Rossini – Ethernet with clock
Roon Rock installed on NUC (also access Qobuz) - Ethernet
2 x PC’s (Windows 10, Windows 11) – both Ethernet
Sonore UPnP Bridge (for secondary Chord HiFi system) – Ethernet (seen in Roon as Squeezbox)
SkyQ - Ethernet + Sky Mini box – Ethernet

The issue
I am a long-term user of Roon as the core of my network. I have happily used the above configuration for a number of years with various SKY and BT Routers. Late last year I decided to cut costs by ditching BT as my internet (and wired telephone) service provider and go all in Sky, nominally the same FTTP service for a significantly reduced cost. As soon as the service was installed, I noticed the network was far inferior in terms of speed. The most immediate limitation was that the PC’s needed time to ‘wake up’ before the internet connection was established. Reluctantly I could live with that.
More annoyingly after a few hours, however, my Roon Rossini endpoint lost visibility. The immediate solution to regain that endpoint was to reset the switch; this worked for a few hours. Looking at old Roon posts it was suggested that SkyQ could be the problem. If I remove the ethernet cable from SkyQ then ‘hey presto’ all is well and the endpoint is restored and the Rossini endpoint remains for a few hours. (It makes no matter if SkyQ is in standby or active mode when I disconnect the ethernet cable).

The change from working to not working is the introduction of the Sky Router and/or the Sky network infrastructure. The previous BT Router and BT network infrastructure worked perfectly.

Hi Brian.

Did you actually mean the GS724T (24-port) Switch? If so, that’s a Managed Switch, with a Web interface, it’s not unmanaged.

With respect to your main problem though, it’s been a couple of years since I looked at Roon communication closely, but basically when your Rossini is freshly booted, the RAAT endpoint within the Rossini puts out a “Roon Discovery Query” broadcast message, which the Roon Core sees, and initiates a TCP session to the Rossini’s RAAT client to register it as a recognised endpoint. Roon can then play to that endpoint (if enabled with Roon Core).

If your Rossini Roon endpoint is disappearing from the perspective of your Roon Core, something is disrupting that communication.

I’m not sure why/how the Sky broadband network elements might play a part in disrupting that communication. Have you by the way updated your Roon Core to the latest release? :thinking:

Thank you so much Anup. You have given me some really invaluable pointers to solving this problem (just checked and it is the GS724T (24-port) switch as you suggested). With a web interface I will investigate this more (maybe there are logs?). I have double checked on my core version being current and it is. It does seem odd as all but my primary Roon endpoint (ie Rossini) are fine. Rebooting the router has no effect either.
Anyway it will be interesting to update my knowledge on how Roon works at more then just my current superficial knowledge.

You’re welcome. Let’s see if we can figure out the root problem.

A couple of questions;

  • Since you own a SkyQ Mini, I presume you subscribe to Sky’s IPTV service?
  • Is your SkyQ Mini connected directly to one of the SR203’s Ethernet port, or to one of the Netgear’s Ethernet ports like your other elements?

If your SkyQ Mini is connected directly to your Sky SR203, and not the Netgear, then I would suggest checking the Netgear configuration to ensure it’s not filtering out any multicast/broadcast traffic (e.g. Disable the [Auto-Video Status] setting, and ensure [IGMP Snooping] settings are also Disabled etc.).

If your SkyQ Mini is connected to the Netgear, then you’ll have to be careful with reconfiguring the Netgear as it may disrupt your IPTV service off that Q Mini. :thinking:


The SkyQ Mini boxes are actually “slaves” to the main SkyQ Satellite receiver (I have them here at home) … they are IPTV based but they use the main SkyQ box as their data source, they don’t go to Sky out on the internet for their content and can’t actually be used without a SkyQ satellite box (I think even VOD content is relayed through the SkyQ box).

They’re not the new standalone Sky IPTV boxes…

Should only be a problem if they’re on different physical networks to the main SkyQ receiver - I’m pretty sure you can even double-NAT them (yes, I know you really shouldn’t do that and it’s messy) running a router inside a router without issues, they just have to be on the same network/router.

Let’s see what Brian comes back with and take it from there… :slight_smile:



In light of the helpful explanations and suggestions you have both given me I am investigatiing my physical network configuration. It is possible that the disappearing endpoint could well be wrongly configured in terms of its connection. I have previously played about connecting the Rossini to the network via the Routers port and at another time via a switched port. I will look at the configuration again to ascertain (and confirm) that there is only ONE active connection.
Another factor is that If I use SkyQ via “WiFi only” all is well - but its pretty slow.

Sky does seem to have a bunch of different boxes, Fibre based, VDSL based, G.Fast based… I couldn’t quite figure out which the SR203 works on.

Good stuff. Do let us know if you learning anything interesting in the process. :+1:t2:

Problem solved. The issue was I had an ethernet connection between my primary switch (Netgear GS742T) and a small multiport repeater feeding the Rossini and SkyQ box… Additionally during some performance experimentation I removed this link and connected this repeater directly from the second port of the Router. After ascertaining that there was no performance improvement I reconnected the switch but omitted disconnecting the direct router connection. So effectively I had two router inputs into this hub.
Thank you so much Anup and Phil your comments/suggestions led me to the solution.