Roon bug(sss...) with Node 2i
Beantwortet
I onw a Node 2i and Vault 2i.
Many bug when playing music from Roon. Worse when connected via Wifi
You surely know what thay are (...), here is a recap from someone on Roon forum:
"The Bluesound 2i variously exhibits the following symptoms:
- Random Playback Stops. Playback randomly stops mid track.
- No Audio from Bluesound. Roon shows the track is playing, no audio is produced. This can continue indefinitely with Roon progressing through a queue and indicating everything is playing normally with no audio from the Bluesound.
- Audio Delayed Start. A request to start a track results in Roon showing the track has started, running perhaps 15 seconds or more until the audio suddenly starts ~15+ seconds into the track.
- Audio Will Not Start. A request to start a track results in Roon showing the track has started and playing fine, but audio never starts from the Bluesound.
- Extremely slow to start or switch tracks (>15 seconds).
- Momentary Loss of Zone. The control unit flashes a message indicating the audio zone is gone and a minute or so later it reappears – typically requiring play to be restarted.
- Zombie State of Bluesound. The Bluesound enters a ‘zombie’ state that requires a power restart to regain control from Roon.
The above issues occur with sufficient frequency as to make the unit effectively unusable."
I partly solved the problems by configuring one of my old Asus router as an access point to which I connect with a Ethernet cable.
I have a Sonos Port right next to the Node 2i and it works absolutely fine with Wifi (very good signal BTW).
I don't expect to debug these problems with you, no time and there are too numerous. But I would like to be reassured that you are working on these problems to make Roon operation more robust via Wifi. The device I bought is supposed to be Roon ready but clearly it is not quite there yet.
Thank you
-
Offizieller Kommentar
Hi Jean-Pierre
The symptoms you discuss are all networking related. It has a lot to do with the fact that ROON, as I understand it, performs a number of decoding BEFORE transmitting data often increasing network throughput. This is because they are a Server-based system with end-points playing.
These issues do not occur when using the BluOS App natively as we have a distributed model where the processing happens directly at the Player level significantly reducing player bandwidth.
Try using our App natively and see how many of the problems persist. Also, check out www.bluesound.com/network101 for networking tips as your ASUS router idea is a step in the right direction.
-
Yes the problems are network related as in your device does not support Room when on wifi. Therefore you shouldn't claim to be Roon ready.
I trust you are working on these issues if you want to fully participate in the HiFi world
Have a nice day.
1 -
Hi Jean-Pierre
Check out www.bluesound.com/network101 to help troubleshoot ways to increase your throughput. With ROON, we recommend you should be at least -55db but -45db is much more ideal. You can check this in Help, Diagnostics.
Thanks for #LivingHiFi
0 -
Thanks for your suggestions. As as I said I've pretty much solved the issue by using a second router as an access point for the Node 2I. I connect to this extra router with a wire and didn't get any problem since.
As for wireless maybe one of those meshed network such as Google Wifi would work. I will investigate this eventually.
Yet I wonder why Sonos works so flawlessly and BlueSound doesn't. But it sounds so much better I believe it's worth the bit of trouble...
0 -
I would like to add onto this, as being an IT professional with over 20 years of enterprise networking I have to disagree this is a network issue.
I have experienced this exact issue described above, and running a fixed ethernet cable has solved the problem.
What I did to troubleshoot:
1) Ran tcpdump on the Roon core and filtered on the IP address of the Node 2i when running on the wireless network
2) Setup a RaspberryPi/Allo Boss combo as a Roon endpoint, connecting wirelessly to the same network, with the RPI sitting next to the Node2i and reasonably receiving the same wireless signal
3) Ran tcpdump on the Roon core and the Node2i while on the wired network
Observations: When the Node2i is setup on the wireless network as soon as I hit play, I can see the RAAT protocol start between the Roon Core and the Node2i. Since most of this is TCP, I can track the health of the stateful protocols used in RAAT. There are no indications of poor wireless network signals, meaning no re-transmissions, out of order packets etc. that you would expect to see given a poor network connection. All sequences sent to the Node2i are acknowledged before the next sequence is sent.
What I do see when the Node2i fails to play is that the Node2i Resets all TCP connections, forcing the core to reestablish these connections. Once the connections are reestablished the Node2i will play most of the time. Given that the Node2i is resetting these TCP connections with no indication of network issues in the form of re-transmissions, missing segments, out of order packets etc, it proves the network stable, and puts the fault higher up on the OSI stack (the application).
The Raspberry Pi acting as a Roon endpoint also never shows any indications of network issues (re-transmissions out of sequence packets etc.) It also plays flawlessly 100% of the time tested. I never see all the TCP connections reset as I do with the Node2i.
Running tcpdump on the Roon Core and the Node2i while on the wired network shows the same types of network data flows, music plays correctly each time, and I never see the Resets of the TCP connections.
Conclusions. Given the fact that I see flawless data transmissions across the wireless network to the Node2i as observed with no re-transmissions due to network errors, and the Resets are coming from the Node2i, and the Node2i works fine on the wired network, it seems there is an implementation issue on the Node2i with the wireless subsystem. Since the Node2i does not give me access to the wireless network interface statistics etc, I cannot provide any additional observations on how the network stack is operating in terms of the buffer, and any buffer overruns etc that may cause the application to Reset the connection.
Please let me know if you want any additional details. I am happy to provide the tcpdumps if you request.
1
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
5 Kommentare