HP Server with Xeon CPU E3-1270, 16GB Ram, Ubuntu 18.04.4 LTS
All music files are on local disks
Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)
Connected via Gigabit Switch (Netgear) to LAN
Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)
Raspberry 3 connected via WiFi (unifi Wifi AP, connected to same LAN as Roon server), with a USB DAC (Topping DX7 Pro)
Raspberry pi 2, connected via WiFi (UniFi AP, same LAN as server) with dietpi and Roon Bridge, using integrated jack
A MacBookPro 2018 model, with an USB SoundCard (Creative X-FI SBX), connected via Wired Lan (same switch as before)
A Samsung S10, primary used as remote control
Description Of Issue
Every now and then, while playing audio, regardless of the fact that I’m using linked zones or single device as output, music stops. If I try to restart it it start quickly skipping over the queue, as if unable to play every track and trying to move to next.
If I try to get the zone detail from the remote control, I see the IP address of the mulfunctioning zone showing the very same IP of the server instead of the IP of the machine hosting the audio client…
I need to restart the zone and sometime also the roon server service on the server side to get back to normal
Hope this helps
p.s. I’m using evaluation license, and have just 4 days left, I’m not sure I’ll be able to do test for long
I’ve managed to connect via wired LAN my main player ( RoPieee on Raspberry 3) instead of WiFi.
It seems to behave better, I still does non see with wrong IP, but I keep an eye on that. I have some stop of music on it, while playing some music as single zone, not grouped. This time no restart of client/server required, just connecting to a remote and hit “Play” button againg, but this is annoying.
Attached to this you’ll find a screenshow showing the problem of a secondary zone (Raspberry2 with dietpi + roon bridge) on screenshot 1 you’ll notice the ip 192.168.172.254, which is the one of the roon server, while on screenshot 2 you’ll find the normal situation (client’s ip correctly shown as 192.168.172.203)
And here you can find another screenshot right after a music stop from the primary Raspiberry 3 with ropieee connected via wired LAN.
As you can see both clients shows with the same ip, which is the one from the server
According to your post here, it seems that the Rasberry Pi3 is the most problematic zone, would you say that this is true? If so, we should focus on this zone to start and then we can take a look at the rest afterwards.
Can I please ask that you let me know the exact local time + date + track of the next time you experience this issue on the RPi3 and let me know this info in this thread?
Ok, let’s say the PI3 is the most used, hence more often I face trouble, nut I agree with you in focusing on a problem at a time.
It has happened hust now, which is 9.05 CET 19/05/2020 with a track from Billy Idol “To Be a Lover (Mother of Mercy)” which was automatically played as Roon Radio after an entire album I selected.
After playing that Instead of playing next from Roon Control I see it skipping from track to track and not playing anything (and as usual, if I go to detail of the zone that was playing I see it with the IP from Roon Core)
I have gone ahead and enabled diagnostics mode for your account and what this action will do is next time your Core is active, a set of logs will automatically be generated and uploaded to our servers for analysis and once these are received, I’ll request the technical team to take a look over them.
Since you mentioned that the IP of the zone is changing to that of the Roon Core, can you please provide an expanded description of how your network is set up and how both the Core and RPi3 fit into the equation?
If you can draw a quick diagram and label the network devices with model/manufacturer names, that may help in debugging this further. Is there just one connection from the Core to the switch or are you using multiple network interfaces on the Core?
Hi,
Regarding the wrong IP: what is happening is that from any Roon Control i SEE the Roon Bridge AS having the IP of Roon Core, but in the meanwhile (from a network perspective) I can reach their real IP.
This is not a case where for some funny reason the box hosting Roon Bridge takes the same IP as Roon Core, since also during the problem I can ping the clients, SSH on them, and reach their web interface amd all. The problem is on Roon Core that is Showing the Clients with Roon Core IP, and is not able to command them anymore, not playing music, etc.
As for the infrastructure is as simple as it can be, I’ve tried to boil all down to 2 boxes connected via wired cable to the same LAN switch, as you can see from the attached image
Thanks for the additional details @Matthew_Dew, let me get this info over to our team and let’s see what further feedback they can provide here, thanks for your patience!
Roon uses the OS level network interfaces for discovery. If Roon is reporting that it can discover a device via the local machine’s IP address, that means that the device is responding to the Roon multicast discovery packets from the core IP address. Based on your logs, it appears that you may be running Roon in a container on a Linux machine. I recommend temporarily running your Roon Core instance on a Mac or PC with a native install of Roon to see if there is something in your configuration that is causing this behavior.
Hi John, in this server it is indeed present a container solution, BUT Roon is not inside a container; it is instead installed on the main OS itself, with native Linux Roon Core install.
If you think this test can be helpful the only chance I have would be to reinstall Roon Core on a small box (a celeron with Win10) and point it to the music folder using SMB (now it’s hosted on the Linux Server on local disks)
Do you think this test make sense? In this case is there a way to move the current metadata to the new installation (since I fear I cannot have 2 Roon servers with same account, am I right?)
