‘Best’ option is if the H2D is the only thing plugged into the Arris, and everything else is connected via the H2D. Then the H2D is the only device providing ip addresses. Humour me. Try it. And I’ll apologise in advance if it still doesn’t work…
Edit - ie the H2D is the only device trying to ‘manage’ the network
Happy to humor you. That makes sense. I will try that and report back. Thank you.
So I did. Thus putting the NUC and the Node on the same subnet. Pretty sure now that it’s the Node’s wifi circuitry.
Stutter still happening when the Roon zone is the Node->Cambridge IA.
Switched zones to the Sonos system. Same room on the same subnet working off the same mesh point. No stutter. Switched the Roon zone to an iPad, no stutter. Airplayed from the iPad to the Node. No stutter. Airplay to the Cambridge IA. No stutter.
So I guess I’m left with 3 options.
What other devices are ppl using that does the same thing as the Node but does it better? I just need a source interface to get music from the NUC into the IA.
Preferably wifi. I know everyone here hates wifi. But I’m stuck with it until I feel like spending several hundred dollars to get some wire monkey to set up something different, and in no event can that happen before the snow melts anyhow.
Thanks everyone. Really greatly appreciated.
Suggestion, probably won’t change much, but at least this is free…
Wifi has a power level at transmitter and an optimal receive level at the other end. Too weak and no good. But, too “hot” and that’s no good. It’s like someone shouting in your ear; you cannot understand what they are saying its just noise.
A few feet line of sight between devices is optimal. Can you, at least temporarily, put the mesh on a table or counter or something across from the 2i? It may not make any difference since the 2i has issues with wifi anyway but its also not optimal to have antennas so close to each other.
One other thing… wifi devices “attach” to Access Points, in this case your mesh nodes, but they don’t have to stay there. I’ve seen issues where a device is perfectly fine on AP one but horrible on AP 2. Does the mesh allow you to see where the 2i attached itself so you can make sure its not moving between APs? Maybe it “just works” on one but not the other and its moving. That’d give you another datapoint to use in troubleshooting.
Also, get the Google up high. I just looked at the antenna array on the Google and where the antenna is on the node 2i and I don’t think they want to be at the same height.
Thank you. I will see if I can make hay with any of that. I HAVE moved the AP around a bit, only putting it close to the Node in my most recent experiment.
Just for a data point, until yesterday the google was atop a 6’ high shelf, and the node is at about waist level on a shelf about 2’ away. But I will play with that and see what happens. Thanks again.
I had the same problem - with Google Mesh.
Router hardwired to one main dumb switch and several other switches & devices connected to that.
Router hardwired to Google (Nest) WiFi Router.
The result was that I had a new WiFi (mesh) network which was much stronger, but that it creates another subnet - so my Roon Core (on a NUC) wouldn’t communicate reliably with my Google mesh-based remotes.
Ditched the Google stuff, bought a more up-to-date Router (AVM FritzBox 7590) and have had no problems since.
If @ipeverywhere’s suggestion doesn’t help, I think the next step might be to try the Bluesound direct wired into the switch again, and see what works. If that works - Bluesound app and Roon - I think we’ve confirmed flaky WiFi on the Bluesound. And at that point, a TPLink RE450 as suggested earlier is probably the best (because it’s cheaper than an additional mesh point with an RJ45) alternative to going out in the snow.
** can anyone confirm a TPLink RE450 plays nicely with Google mesh?
Edit - as to what changed to break something that was working before, it wouldn’t surprise me if the Google kit updated itself without telling you. I’m guessing, obviously…
I have a FRITZ!box as Router an two Fritzrepeater 1200 (with RJ45-Ports connected to a Pulse flex, no problems since then! Player are found in the BluOS-App and in Roon)
Easy, not to expensive. But in general: try to avoid to access your player (clients) via WLAN…
Hope you find a solution!
You’re not the first person to be frustrated, to the point of giving up, about Roon with Bluesound
One has to be careful not to paint with such a broad brush. The product line of Bluesound and NAD is extremely broad. What has caused so many problems in these products is Bluesound/NAD taking advantage of Roon’s previous looser policy to claim certification when in fact many things were not working properly. And then they took years to fix issues and only really started to clean things up when Roon took the hard stance that you’re not certified if everything isn’t working and you’ll lose it it you don’t. This was the right answer IMHO… but NAD/Bluesound should be blamed for taking so long to prioritize fixing issues.
Having said all this you still have to do proper diligence to make sure you’ll not have an issue (which is good practice for any device you buy if you’re using Roon)…
I have 10 NAD CI720s with bluesound and 2 Nodes that work flawlessly in a wired fashion.
Many users have reported that the current Bluesound products are working much much better with wifi after a recent firmware release: BlueOS 3.10 released 18/8/2020. Of course that doesn’t help the OP with wifi problems with his Node.
And I’m not aware of users have problems with most Bluesound devices if they wire them.
The issues with the Gen1 NAD CI580 have never been addressed and it doesn’t work wired or wireless.
I could go on… but my point is there are some great products from NAD and Bluesound and if you’re careful in what you chose, do proper diligence and set them up properly you’ll likely never have issues (like me), but you can get burned if you’re not careful. But I would not rule out using everything from Bluesound/NAD…
For me, with a Roon Nucleus and 2 x NAD CI580’s wired together in a rack with a UniFi Gigabit switch, it was absolutely unusable to the point where we ripped out the Roon and just went with BluSound because it at least works for the client.
I ordered a Rpi. We’ll see how it goes before I return the Node.
I noted the specific problem with the CI580s in my post.
So the tech over at Bluesound just suggested I try using the BluOS app to play through the Cambridge CXA61. Which I will do as part of a trouble shooting diagnostic. Interesting thought which raises a question—assuming there’s any difference discovered.
IF that makes a difference, could I set up the BluOS as a Roon zone so that I could then access the 750gb local library that’s on a SSD attached to the NUC thru BlueOS? So that instead of seeing Node as a Roon zone, the zone would be “BluOS.” And if it can be done, would that matter? It would seem to me that the Node’s wifi circuits are still in play. But if it can be done, and if it works, then that would let the Node’s wifi off the hook and point to Roon software as the culprit? Maybe?
I think this may be part of a Bluesound buck-passing effort, as he wants to blame Roon, while Roon wants to blame Bluesound. (Both of which seem to let Google wifi off the hook, but since the Node playing Roon is the ONLY place in the house with a problem, I think Google gets a pass here.)
Bluesound has passed the buck for years. It took them over 1.5 years to fix their sync problem and until it was fixed with a firmware update on their side they continually blamed Roon. While my NAD CI720s and Bluesound Nodes work great for me in a wired state, I would never buy a product with BlueOS in them on a promise of future functionality or a promise to fix a current bug. I don’t believe anything that comes from them about the future and I don’t believe them when they pass the buck.
Follow up. So I just went to play thru BluOS and lo I notice that “Roon” is (I guess) a source option in the sidebar.
So now I’m completely flummoxed. So I go to Roon. Choose an album in the local library. (Allman Bros Fillmore East, just to keep a constant reference.) Play. Leave zone wherever it already was. Go to BlueOS. Choose Roon in the sidebar. Allman Bros coming out of Cambridge CXA61 with NO STUTTER.
WTH? What is playing what? I have no local shares set up on BluOS, so it has to be coming from the NUC over wifi.
Talk about friggin’ ghosts in the machine.
Can anyone explain this? My mother always told me that “you don’t have to invent the telephone to use it,” which was her way of saying “if it does what you need it to do you don’t have to understand it.” But after almost a week of dealing with this, to stumble onto an apparent “solution” as a result of blind luck, but which I don’t understand even a little bit is a sharp kick in the head.
Screen shot of signal path attached.
I guess that begs the question ‘how were you doing it before?’…
Great question.
On one of three iPads that I have. Which is the only iPad that has BluOS installed at the moment because that was the one I used to set up BluOS when I bought the Node.
Here’s the sequence that I WAS doing before. In Roon on iPad. Choose album. Tell it–in Roon–what zone to play to. I.e., Node. Stutter. I’m pretty sure that is how Roon is supposed to operate…except for the stutter part.
Or, on a MacBook Pro Roon app, choose album, send to Node while in Roon. Stutter. That MBP doesn’t have BluOS installed yet.
Now…
In Roon. Choose album. Switch to BluOS app. Choose Roon as the source. No stutter.
What I guess that means is that in order to avoid the stutter, I need to start music using BOTH apps. I guess I have to now download a BlueOS app to two other iPads, two iPhones, an iMac and a MacBook. It also means that no one in my family will ever use the system because no one has the patience to go thru this Rube Goldberg process just to get a decent signal.
Does that make any sense at all? Why would the direction/sequence of the two apps working together matter? Especially when the issue seems to be the wifi signal?
When you configure BlueOS device within Roon it will appear as a source in the BluOS app. There is some interoperability. When there was a sync issue with BluOS devices within Roon you could group them in BluOS and then Roon would only see one device and this was a sync workaround. You can also start and stop something your originally started playing in Roon from the BluOS App. I believe this is just a side effect of the integration with Roon and it really not intended to be in any way a normal use model. You should be doing everything in Roon except kicking off firmware upgrades of your BluOS devices from the app.
In regards to why you’re seeing no stutter when you’re kicking off play in the BluOS App on an album you’ve selected in Roon… I’m guessing you’ve also got your music loaded in the BluOS app (meaning you configured where your music library is from within setup in the BluOS App). If yes, I’m guessing that BluOS is likely playing the album itself…versus via Roon and thus no stutter, but this is just a guess and again is likely just a weird side effect of the integration but not an intended design flow. I can’t test as I don’t have any my BluOS app configured with any music by itself…
And I gotta say, I can’t accept that as a solution. Just a workaround. And a completely illogical one at that. Like figuring out how to arrange a bunch of random levers and buttons in a video game that makes the door to the dungeon open. Accidentally discovered, with no explanation. And I’d bet not replicable in another system.
I get the sense that a lot of the folks on this forum are pro audio folks who may work with clients to set up systems. Would any of YOU accept that as a solution? (And I’m not sure that a hardwired connection between Roon and Node would fix it given how wonky this workaround turns out to be.)
As of now, the Node is STILL getting the same wifi signal. It’s just that it’s not stuttering if you push the levers and buttons in the right sequence.
