For my “casual” listening and to manage my local library, I’m using JRiver Media Center on a MacMini dedicated to music. I’m experiencing problems with both the Bartók and the Network Bridge.
For weeks, I had no problems with playing music from JRiver to the Bartók. I already had problems, however, with the Network Bridge disappearing after a few minutes of listening, then reappearing after some 10-20 minutes or so.
But since a few days, things have got worse, both devices being completely invisible to JRiver. In the past, switching the Bartók off then on (physical switch) did get it back online, but not any more. What is particularly puzzling is that both devices — Bartók and Network Bridge
are still live on the ethernet network, visible from an IP scanner and accessible through the browser interface ;
are still visible and controllable by Mosaic ;
are visible and accessible for the Roon server and can be played on via Roon Remote ;
and, the weirdest of all : from Mosaic, the JRiver UPnP server has occasionally been visible and accessible for a certain time, while JRiver wasn’t seeing Bartók !
The devices are wired to the MacMini, no wifi involved.
What I tried, without success :
quitting and relaunching JRiver ;
restarting the MacMini ;
FWIW, my Sony TV and Oppo DVD drive are both seen by JRiver when ON.
All this, in my opinion, points towards a problem with the UPnP implementation in Bartók and Network Bridge. But I know that UPnP is a weak “standard” and that the quotation marks are de rigueur, when mentioning it… If you think it’s pertinent, I can also post on the JRiver Media Server forum.
I’m sorry that you are having problems in your setup. The issue that you describe is typically related to multicast discovery packets being blocked somewhere on your network.
Can you please describe your network setup along with brands and models of the router, switch(es), and wireless access points?
Thank you Andrew. I must say I was afraid you’d answer something like “we don’t support JRiver. Only MinimServer.” [^1] I’m (very) happy you’re willing to help finding a solution to this issue.
Answers to your questions :
The router is from my ISP (Swisscom, the historical swiss phone operator). Seen from IP-Scanner, the manufacturer is identified as “ASKEY COMPUTER CORP” (see attached screenshot).
From the router runs a Cardas Clear internet cable to an AQVOX AQ-Switch V1 (it’s a modified D-Link).
From this switch runs another Cardas Clear internet cable to an AQVOX AQ-Switch SE.
The MacMini is wired to the router.
The Network Bridge is connected to the first switch (V1). The DVD Drive and the TV also.
The Bartók is connected to the SE switch.
The router is the wifi access point. No extender involved. The mobile devices (iPads, iPhones, MacBook Pro) do connect to it.
Olivier :-{)
PS : Bartók is at IP 111. It’s an allusion to one of my favorite opus : the last piano sonata by Beethoven.
[^1]: Yes I’m aware of this and I understand your reasons. But 1. MinimServer is not up to my functional requirements. 2. So far, I couldn’t manage to set it up to working order… maybe it’s too “nerdy” / technical for me. With some help, I’m willing to try again, if need be.
Based on your configuration I’m guessing that the ISP router is trying to be smarter than it should be. I can’t find any published documentation on that product and don’t know if you even have access to the settings that would need to be modified.
The issue here is that UPnP uses a protocol called multicast to do device discovery. Without going into all of the technical details, some network products will selectively block multicast for various reasons. In most cases this has to do with optimizing performance, but the way that it’s done in most consumer products is just stupid. This is one of the reasons that we recommend against any sort of managed switches in home applications. The way in which things can (and will) break is really ugly.
Your switches aren’t managed (as far as I can tell) so they should just treat multicast as broadcast which is what you want in this situation. The switch inside that router is most definitely managed and it may be attempting to shape the multicast traffic.
Before we go any further, is the Wi-Fi connection on the Mini enabled? May sound like a stupid question, but it’s a requirement to be active for certain functions (like unlocking with an Apple watch) so it’s valid. If it is enabled then turn it off and reboot everything (mini, router, dCS products, etc) and see what happens.
If that doesn’t help then proceed…
A quick test would be to move the Mac Mini’s network connection to one of the other switches (doesn’t matter which one). Basically you want to establish a network path that doesn’t require traffic to flow through the router. In the case of JRiver the Mac is operating as the UPnP server and control point so the Wi-Fi connection is irrelevant. In the case of mosaic the Bartók or Bridge is taking the role of UPnP renderer and control point so, again, the Wi-Fi connection isn’t part of the equation. This is very fortunate.
Try connecting the Mini to one of the other switches and be sure that Wi-Fi is completely disabled on the Mini as well. Reboot the Bartók, Bridge, and the router at the same time. Run this way for a bit and see if the problem returns or if the behavior changes in any way.
So I did as you said : I connected the MacMini to the first ethernet switch after the router. Then :
MacMini OFF
Bartók OFF
Router OFF — wait half a minute
Router ON — wait until it has completely started and connected to the internet
MacMini ON
Bartók ON
Bartók did appear in JRiver for a few minutes, then disappeared again.
So I went to the configuration pages of the router. There, I discovered that the “Automatic port forwarding (UPnP IGD)” was OFF. I switched it ON and repeated the above six steps. → Same result : Bartók did appear in JRiver for a few minutes, then disappeared again.
Below are two screenshots of “maybe relevant” configuration pages for the router. If nothing can be done there, I may be “out of luck”…
Then, I guess, the solution should be to set up a different network, with a trustworthy router, dedicated to the music. Would it be possible to bridge it to the domestic network ? (for remote control) If not, I suppose a router with wifi access would be the solution and my MacBook and iPads would be connected alternatively to either network, according to the current needs.
First off, the UPnP setting on your router doesn’t have any impact on music playback. This is to allow devices on the network to re-configure the router without having to provide credentials. I’d recommend resetting it to the ‘off’ state as it’s a security hole.
Do you have the firewall enabled on your Mac Mini (System Settings > Security and Privacy > Firewall)? If so, please disable it and see if the behavior changes.
OK, so the next step in troubleshooting an issue like this is to get the relevant components (Mac Mini and one of the dCS devices) onto an isolated network and test that way. I typically recommend Netgear Nighthawk AC1900 routers for this as I know that the default configuration works. If this ends up solving the problem then a common solution (used a lot in the UK) is to put the good router immediately behind your ISP’s router and connect the whole house to the good router (with Wi-Fi disabled on the ISP’s router).
Having said that there’s a good chance that this is a bug in JRiver for MacOS or even in MacOS itself. If the server is always visible when using Mosaic Control, but the endpoint sometimes isn’t visible in JRiver then this may be the case. Remember that the UPnP control point function (discovery and browsing) is running on the dCS device (not the tablet) when using Mosaic and on the Mac (not JRemote) when using JRiver.
Let me see if I can get this to break in my setup. If so I might be able to point you in a direction that will work. It will take me a couple of days as I’ll need to get a JRiver server fired up on a mac that would represent a valid test case.
I have a Nighthawk X6S left over in my home. Is it usable at least to make a valid test such as the one you’re suggesting? Anyway, I need a few hours to do this kind of testing and I’ll do it over the weekend.
As an aside: I’m completely with you that it looks like a problem of interaction between the ISP router and the multicast protocol and/or a bug in JRiver; but what could be the difference, as UPnP devices, between an Oppo DVD drive or a Sony TV — which are visible to JRriver — and dCS devices — which are not visible? I’ve also noticed the same in the opposite “direction”: the Oppo drive can access the JRiver server, while Mosaic doesn’t see it.
That should be fine. Just reset it to defaults and make sure it has the latest software.
This very well could be a bug on our side and that’s what I’m hoping to get to through the process of elimination. Isolating the network will help a lot there.
Keep in mind that the UPnP renderer functionality (what JRiver is talking to) is really only there for convenience and a certain amount of backward compatibility. We don’t use that interface (or any part of the UPnP renderer functionality) for native playback in Mosaic. We only use UPnP to talk to media servers. Control and playback management are all handled internally using a proprietary mechanism.
That means that the UPnP renderer presentation is implemented using the most narrow feature set and most basic interpretation of the UPnP standard so as to be the most compatible. There’s a chance that your other devices are doing something more advanced with their discovery mechanisms which is making JRiver happier.
Having said that I did fire up JRiver MC25 on a Mac Mini with a local music library. I have 4 other UPnP servers and 10 renderers (dCS and non) on this network so it’s more of a worst-case scenario as far as UPnP discovery goes. I was surprised at how long it took to discover the devices on the network (well over 8 minutes) which I’d consider to be excessive for a control point. Currently have an album on repeat to a Rossini and as of yet I haven’t observed any issues with playback or with devices disappearing.
It focuses at the TCP session layer of the UPnP protocol (as opposed to Ethernet physical layer, or layer 2, or IP layer 3), and interrogates the network to identify UPnP devices. I used it successfully in the past to identify a problem with my Melco source.
Install the app on your Mac and connect that Mac via wired Ethernet to the same switch that your JRMC is sitting on. When the App is launched and the [Search] button is clicked, it issues an “SSDP Discover” M-Search packet, to which any UPnP capable device in the network should respond.
You can see in the first screen-shot, my Macbook (.28) issuing the SSDP:Discover call, and the Melco (.11) responding with a slew of UPnP services. The 2nd screenshot shows my dCS Vivaldi Upsampler (.38) responding to the same discover call. And finally the last screen-shot with the dCS Upsampler showing up as a Renderer device and it’s services.
It won’t fix your problem, but might point to further clues in resolving your issue.
Just to circle back around on this my testbed ran overnight without any issues. This suggests that there’s not a fundamental compatibility issue between what JRiver is doing with respect to our devices.
I didn’t ask prior, but are you running the latest version of JRiver (MC25)?
Not so good news : Bartók still has issues in the UPnP department.
As advised by @Andrew, I proceeded in two parts. (Yes, I do have the latest version of everything, firmware included).
First part
I set up an isolated network, using the Netgear Nighthhawk X6S I have on hand, with :
MacMini server
Network Bridge
Bartók
the two AQVOX switches
Result : everything works fine, Roon et al., except for Bartók not beeing visible to JRiver.
I don’t remember if I also tested with Audirvana (see below).
Second part
I connected the X6S to the main router (from my ISP), in order to bring back internet access and remote control to the hifi gears. It’s the configuration I’m using right now. I have documented the topology (main devices) :
If I switch Bartók OFF then ON, it reappears for a few minutes in JRiver, then disappears.
To assess wether it could be an incompatibility with JRiver, I also tested with Audirvana 3.5.13. I have the same situation : Network Bridge is visible — and Audirvana is able to send it music —, but not Bartók :
(In the background window, JRiver. UPnP Analyzer sees a TV box that JRiver, in “pure audio” mode doesn’t see.)
I must say that it looks more and more like an issue inside the UPnP code of the Bartók… I do stress that everything else works fine with it : I can play music with Roon and get the expected delightfull SQ; Airplay is also available.
Bartok and Bridge run the same UPnP renderer code so if there’s a problem specific to one it should be the same on the other. From your diagram I do see that you’re continuing to use the cascaded aqvox switches and as this is primarily a connectivity issue I’m starting to suspect that one of them doesn’t like this configuration.
Try with just the mini, the Network Bridge, and the Bartok connected to the Netgear. No other switches or any other hardware.
I agree with Andrew. The cascaded AQVOX is the most likely culprit. Easily confirmed if you plug your MacBook Pro/USB Analyzer into the same AQVOX switch as the Bartok and see if the latter than responds to the SSDP:Discover multicast M-Search frame. My guess is your cascaded AQVOX switches are somehow blocking multicast frames between them (maybe in an effort to reduce multicast broadcast storm).
As the two AQVOX switches are two different models, I’ve indicated it on the diagram.
There’s still the same problem: after being swtiched ON, Bartók (UPnP) is visible for a few minutes, then disappears… Network Bridge still OK.
It very much looks like the culprit could be the AQVOX Switch SE. This evening (or tomorrow morning), I’ll switch the two AQVOX and we’ll see… (not practical to connect Bartók directly to the Netgear.)
First, I installed a “normal” D-Link switch in front of the Bartók, instead of the AQVOX. After being powered OFF then ON, both dCS devices appeared for a while in JRiver. But after a few minutes, we get
dCS devices visible for UPnP Analyzer but not for JRiver
In French, i’d say “I’m losing my Latin…”
I think the next step could be to take both AQVOX switches out of the network. This evening I’ll bring a “normal D-Link” from my office and test again.
What model is the “normal” D-Link switch? If it’s a managed model then it could be adding its own set of variables.
In troubleshooting something like this you need to eliminate as many variables as possible. That means one dCS device and JRiver. The aqvox switches are suspect so they need to be out of the equation for troubleshooting.
Test with one normal, unmanaged switch, the Bartók and JRiver then go from there. Due to the way that UPnP can get goofy in the Mac environment I’d highly recommend getting the network set and then power cycling everything before testing. If that’s stable then add in a second normal switch connected to the router with just the Network Bridge connected to it. Nothing else. Again, power cycle everything.
If you’re using managed switches for testing then that is going to create a problem. In fact, managed switches are quite famous for causing this exact type of problem.
Is there a specific order that you’d advise for the system startup? My logic:
MacMini
(Roon is at the end of the startup sequence, but not JRiver)
Bartók (ev. Network Bridge)
JRiver
I’ll be away from home the next few days, so won’t have the possibility to proceed to further testing. I’ll be back on Tuesday, the 2nd of July. (I’ll miss my music. )
)