The startup order you listed is what I’d recommend. In theory it shouldn’t matter, but I don’t know how much JRiver makes use of the in-built discovery functions in MacOS. I get the impression that it’s more than they let on given how the software behaves. That’s not a slight against them, but in an effort to be all ‘warm and fuzzy’ MacOS does some odd things with device discovery.
After some more testing, I think I’ve identified the culprit. First, I’ve taken both AQVOX switches out of the equation and connected like this :
In this configuration :
- Network Bridge disappears [from JRiver]
- Bartók OK
Next configuration :
In this configuration :
- Network Bridge OK
- Bartók OK
Next configuration :
In this configuration :
- Network Bridge OK
- Bartók disappears
Next configuration :
In this configuration :
- Network Bridge OK
- Bartók disappears
Next configuration :
In this configuration :
- Network Bridge disappears
- Bartók OK
So, in the end of the day, it looks like highly probable that D-LINK switches are causing the problem — or, at least, are a significant part of it. I put “switches” in the plural because the AQVOX switches are modified D-Link and this very fact seems to corroborate the diagnosis.
What’s your take on this ?
I’d like to add that in every one of the above configurations, Roon does run flawlessly.
My personal take is that the culprit is likely JRMC, and it’s (in)compatibility somehow with your network - at a networking level, there’s no reason why your configuration above shouldn’t work. Are you on JRMC 25.0.71 (MacOS), there seems to be a whole range of fixes. You might want to give that a try.
Just looked up the specs on that ZyXel switch and I see a couple of issues:
-
It’s Fast Ethernet only so the connected devices are going to do some interesting stuff in terms of flow control. I’ve seen issues with 100mbit devices in the middle like this in the past, It just doesn’t work well.
-
It is an unmanaged switch but it has some layer 2 management functions implemented with the “priority ports.” That switch is going to try to be smarter than it should be and could end up messing with traffic.
I’ll be the first to admit that I’m not a fan of D-Link given prior bad experiences. It’s quite possible that their switches are doing something atypical with traffic management and that’s causing a problem. Having said that I’m in agreement with @Anupc that there seems to be something fishy going on with the way that JRiver and/or that mac are handling device discovery.
@Anupc and @Andrew, thank you very much for trying with me to solve this issue.
I’ve checked the JRMC version : it’s 25.050 and it’s the latest on MacOS.
So, I guess, my next step should be to install two “up-to-date” and “fair-players” ethernet switches. Could you please recommend me one or two suitable ones ? I don’t have the technical knowledge to make an informed purchase. Thank you very much in advance.
Olivier :-{)
You might want to check JRiver’s Support Forum;
The latest MacOS version 25.0.71 was released on June 28th, and seems to have a significant number of fixes since your version. It can be downloaded here;
http://files.jriver.com/mediacenter/channels/v25/latest/MediaCenter250071.dmg
I’d say give that a try before you switch Ethernet switches 
For switches I’ve had good results with the SG110 series from Cisco as well as the GS105/GS108 from Netgear. For the Netgear switches you want the original version in the blue case not the ‘e’ version in the grey case.
I could make some further testing with another ZyXel switch and here are the results and what I can say with a good dose of certainty :
-
Everything works fine — i.e. as expected — with ZyXel switches (at least with those I tested) : every device — dCS and others — remains visible and functional in JRiver MC. The situation remains stable along the days and JRMC as a UPnP server remains accessible for playback by Mosaic on iPad.
-
It’s only when using D-Link switches — unmodified ones or AQVOX modified — that happens the problem of “lost contact” between dCS units and JRMC.
So, in the end, we have this :
-
As long as you don’t use JRMC — i.e. you use only the Roon infrastructure for network playback — you won’t experience any problem, either with D-Link switches or with dCS units.
-
If you’re using JRMC, you won’t experience any problem with your dCS units, as long as you don’t use D-Link switches. And should I add MacOS into the formula? Truth is I didn’t test with a Windows machine.
As for me, since I’ve added a Rossini Clock to my Bartók, I’m not in “need” for AQVOX switches and get a “decent” (tongue in cheek) sound quality with ZyXel ones. So, as far as I’m concerned, I can say “problem solved” — even if it’s with a slight feeling of “voodoo things happening in the background”.
@Andrew : maybe you’d like to “tame” this voodoo ? Would you advise me to post on a JRMC forum ? And what about making AQVOX aware of this issue ? Do you think it’s worth it ? I’m afraid we have a situation with three — or even four — protagonists (JRiver, D-Link, dCS, AQVOX) who can mutually blame each other for the problem… Without even saying anything about Apple. Computing remains maybe “voodoo” after all… 
In the end, gentlemen, I thank you very much for helping me and hinting me towards the solution !
All the best.
Olivier :-{)
1 Like
At this point there’s really no information on the root cause of the issue other than the fact that your configuration doesn’t work with DLink switches. That implies that the switches are doing something stupid with multicast traffic, but doesn’t prove that they are at fault. I’m tempted to blame the switches as DLink products have been a nightmare for me over the years. Given their history I doubt that they’ll do anything to improve the product which is just as well as there are other options which do work consistently.
Echoing a comment from another thread… trying to improve your system by changing out the switch for a “better” one isn’t going to work as that’s not how networks work. The best switch is the one that ensures that all appropriate traffic gets from point A to point B 100% of the time. All of the other stuff floating around out there about clocking, jitter, and <insert_audiophile_buzzword_du_jour_here> is clearly demonstrating that the person making the statement is either uninformed or dishonest. I’d like to think that it’s always a case of the former, but the latter tends to come up all-too-often in high-end audio.
People, please stop trying to audiophile-up your networks. At best (and I mean BEST) there will be no difference. Most of the time the tweaks will end up making the network perform sub-optimally (or not at all).
1 Like