Core Machine (Operating system/System info/Roon build number)
ROCK (10th gen NUC) running on 1.7 (build 571) Stable
Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)
Unify setup with 3x AP’s
2x UniFi AP-AC-Pro
1x UniFi AP-nanoHD
Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)
4x Raspberry Pi 3 - Hifiberry Amp2 (Roopieee 2.535 stable)
4x Bluesound Powernode 2i (BluOS 3.8.13)
1x Bluesound Powernode 2i (BluOS 3.8.13)
(All devices running on Wireless)
Description Of Issue
I bought these Bluesound Devices because I find their audio performance to be superior to the Raspberry Pis. The problem is… I no longer use most of these Bluesound devices, cause they honestly doesn’t work well with Roon at all.
Drops outs
Music not starting at all (often shows “Tidal is loading slowly” error message when this happens, but I don’t think it’s Tidal related at all…)
General annoyance that is totally not acceptable.
I think Roon need to look at this seriously, or remove the Roon certification for Bluesound, because right now people get cheated buying (expensive) Bluesound devices under the impression that they will work with Roon.
I’ve seen multiple other threads about this.
…and it seems people get pointed to Bluesound or Roon and blame gets put on Wifi and other stuff. I can just say that my Wifi is SUPER stable. (Absolutely 0 issues with the Raspberry Pi-devices, or other devices on the network)
I just had issue happen…
Had 3x Raspberry devices playing music non stop for ~24 hours or so.
I tried to include the Node 2i into the group of devices, which caused music to stop.
After this I couldnt’ get the Node 2i to play music neither in a group with other devices, or itself (through Roon).
Testing it through BlueOS directly works. But for some reason starting playback through Roon does not work.
Finally rebooting the Node 2i, and it seems to work again… I am rather sure that there’s something bad going on in the software implementation in the device.
The Bluesound devices report great signal strength (-43 dBm right now)
Observations
It seems that the more Bluesound-devices I try integrate into a group or play in general, the more likely the problems are to start happening. Meanwhile the Raspberry Pi’s just work flawlessly.
I’ll gladly help try pull more data out of the devices or observations
I’d appreciate if someone from Roon support could engage here directly, or reach me privately so we can try work this out.
I have only two Blusound devices and have not had similar problems but I have had one that may be related. If there are multiple control devices in operation (BluOS on iPad, iPhone, PC and/or Roon on PC), the system can become unresponsive to all of them. Perhaps that is an uncommon and unexpected arrangement but it is annoying.
Have you tried running your bluesound zones connected via Ethernet as a test? Even if your WiFi is super stable, there might be issue with communicating with the BluOS devices via the Roon Ready protocol on WiFi. I would test Ethernet just to eliminate this aspect.
When this occurs, what does your Signal Path show? Is the processing speed above 1x?
I have been with ROON for about a month with Node 2i and flex 2i speakers over AT&T fiber WiFi across two floors. Absolutely no problem, not even once!
I would suggest you check your router settings and ensure all the devices are on 2.4G and unused channel (deselect ‘auto’).
Hi there @noris thanks for trying to assist.
Worth mentioning. If using the BluOS app to play music directly (not Roon). The Bluesound-players seems to work. (so bascially, once the issues in Roon starts, I can start up BluOS and get them playing through the BluOS-app…) It’s worth mentioning, I did uninstall BluOS from ALL my devices to make sure that there can’t be any software doing interruptions to Roon playback… This didn’t help.
It is funny, in Roon, I can easily group up my 4x Raspberry Pi’s in a group and play something. They respond quickly, play in sync, and always work, super stable.
As soon as I add one or more Bluesound-devices to a group, the problems begin. I highly would appreciate if the Roon-team could look into a more complex Bluesound-setup and figure out what could be going wrong.
I wonder if people at Roon has actually tried to setup an environment with multiple Bluesound devices + other Roon-devices and play with it for real? I have 8 zones in my home, so I have a rather complex setup.
How do I pull information out of Roon about what is actually happening? If I setup a group of ~5 devices (2-3 Bluesound) and press play, it’s always super slow to start (if it starts). Takes like 5-10 seconds (with only Raspberry Pi’s it instantly starts). And then sometimes things just don’t start, usually with the “Tidal is loading slowly error message”.
What can I do at this point to try figure out more? Is there any logs I can read in the Roon Core? How do I access them?
The signal path you ask about is just showing the “purple diamond”/“lossless” for every device. I can’t see any other relevant data really in that?..
Hi again @noris, I can confirm that after hooking the Bluesound-devices up through Ethernet, they seem to work in the Roon system without issues. That is confusing. I have tons of other devices working flawlessly on the Wifi, including 4x Raspberry Pi’s that run Wifi and Roon…
Definitely seems like the Wifi-implementation on the Bluesound-devices is not great… I don’t have wire ran through my appartment, so running them all on ethernet is really not a solution at this point… .
Observation 1
Having ONE bluesound device (on WIFI) grouped with Raspberry Pi’s seems to work usually… It’s the moment I try to group more Bluesound-devices to the group where at least one is hooked up to Wifi that the errors appear. (having more than one device as long as they are hooked to ethernet cause the issues)
Observation 2
Putting all my Bluesound devices on the 2.4GHz band instead of 5GHz seems to have made it slightly less buggy, but did not fix the issues. One time I managed to get all my devices playing on one group, but after ungrouping, and trying again I got the issues again.
Suddenly one of the Bluesound devices gets reported as “missing” in Roon, or I get the “Tidal is loading slowly” error message.
Thanks for testing the Ethernet aspect. Since the issue does not occur on Ethernet, I wonder if your WiFi channels are over-congested? You should be able to do a network scan via the UniFi, might be worth a try to switch out channels.
You could also take a look at the Bluesound diagnostics under Bluesound’s IP Address in a web browser -> Diagnostics -> More to see if there are further clues there. Since they’re working via Ethernet though, it would be best to reach out directly to Bluesound to troubleshoot any issues with the on-board WiFi.
Hey @noris. No my WIFI is reported as 97% experience, which I assume is good.
Don’t live in a very congested area, so that should not be an issue.
Worth also noting that all my other devices works flawlessly…
I have checked the Diagnostics section of the log and from that,
signal: -48.00 dBm
last seen: 10 ms ago
SSID: W_2G
DS Parameter set: channel 1
(Seems solid)
But in the log I also see chunks of this, which does not, without knowing anything about RAAT implementation, look too good.
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 80949 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 81312 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 81675 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 82038 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 82401 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 82764 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 83127 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 83490 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 83853 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 84216 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 84579 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 84942 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 85305 [2]
Jun 30 18:52:20 (none) user.info ./ms.pl: main::HttpRequest ./ms.pl (1030) [1] 192.168.1.10: /Playlist?start=0&end=200&_nocache1593543140466
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 85668 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 86031 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 86394 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 86757 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 87120 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 87483 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 87846 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 88209 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 88572 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 88935 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 89298 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 89661 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 90024 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 90387 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 90750 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 91113 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 91476 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 91839 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 92202 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 92565 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 92928 [2]
Jun 30 18:52:20 (none) user.warn RAAT: dropout of 363 samples at 93291 [2]
Also, it seems that RAAT takes up a huge chunk of the CPU of the device (59,3%)
raat 1057 59.3 2.4 48436 6108 ? Sl Jun30 505:15 raat_bluos -c /var/data/raat.json -z 1 -i BluOS:90:56:82:9f:7b:7f -d /var/data/raat -b Bluesound -M PULSE 2i -v 3.8.13 -e -C -U 104 -G 104 -N 1 Master Bedroom
I also, along with many others, have had issues with Bluesound products and Roon when wireless which all went away when wired. Bluesound repeatedly blame wifi or Roon which both work fine on their own. I had always though it to be a Bluesound wireless implementation issue.
However I have noticed anecdotally that those having problems like myself seem to be using Ubiquiti APs whereas those that seem to be able to run Bluesound and Roon without wires do not. Is there some kind of incompatibility between Bluesound wireless and Ubiquiti I wonder?
I had ASUS mesh before ran by their high end ax11000 router + nodes and had even more issues then.
Installed Unify since it is supposed to be the most reliant and stable more or less… Network in general became more reliable (a bit slower) but issues with Bluesound + Roon remained.
We have managed to reproduce this behavior in the QA lab using BluOS gear via WiFi and we’re working directly with Bluesound to resolve these issues. In the meantime, we would suggest using a direct Ethernet connection instead of WiFi for your 2i devices.
Hi @noris, that’s great news! I will keep my Bluesound gear for now and hope things gets resolved over time. I’ll use powerline ethernet adapters for now, which helps.
If you need any input from me in your troubleshooting, feel free to reach out.
The Bluesound support sent me a batch of settings suggestions for my unify APs (one example min RSSI 60, which is not really cool…) anyway their suggestions didnt help.
We continue to work with the Bluesound team on improvements to the BluOS/Roon Ready integration, but you should be aware that any changes for this issue will need to be implemented on the BlueOS side.
.