I have Roon Core running on ROCK. I first replaced the OS on one Roon endpoint with Audiolinux running Bridge. Sounded wonderful. When I tried to set up a second NUC endpoint similarly for my headphone system. Things went very badly. For some reason Roon will only recognize one bridge PC at a time. If I turn both on then Roon gets confused and will not let either play and in fact displays a combination of information of both under Audio settings.
I have tried everything to fix this and have not been able to work out a solution with the Audiolinux developer. Both units have different hostnames and IP addresses and I can use Putty to remote them as they are headless. I have rebooted my LAN router, reinstalled Audiolinux on both PC’s and rebooted the Core many times.
I know that Audiolinux works on both as I have been able to get each to play individually but never when both are booted up. The sound is great so I would love to get this working.
Any help is greatly appreciated!
Did you setup the two independently or copy and reuse an image from one in the other?
I set up each individually using a separate USB stick. Audiolinux allows you to boot from a USB stick and even set up a ram boot. It sounds great but I just cannot get both Roon bridges to show in Roon audio settings.
I have moved to static IP addresses and made sure that hostnames were unique but so far the best I can do is to have both up but only one showing in Roon and playing music. The second machine to boot up gets shown and available in Roon.
I think the first step here is to enable some diagnostics on your account so our technical staff can get some more insight into what’s going on here.
However, before I enable this feature, I’d like to ask for your help ensuring we gather the right information.
First, can you please reproduce the issue once more (boot up both devices and try to play to one) and note the time at which you do this. Please also note which device works and which one doesn’t and what you’re playing to that device. Then respond here with that information, and I’ll make sure we review the diagnostics related to that timestamp.
Thanks for staying with me. I will do what you suggested but first let me tell you what is currently happening during my troubleshooting.
At the suggestion of the Audiolinux developer I just finished running Roon update Linux commands on both bridge PCs. I then stopped and restarted those Bridge services and rebooted the Core PC.
Now it gets really weird. I was once again back to just having my Office Bridge PC show in Roon Control and play music so I decided to stop audio services on that PC to see if my Den Bridge PC would possibly then show up as available again.
Now even with the services on the Office PC turned completely off it still shows as available and connected in Roon Control. The weird part is that music is now playing in my Den!!!
There is some part of the system that is very confused. I am starting to think that the Core is not communicating properly.
OK. I started your test at 8:54am EST US.
With my Office PC turned off I rebooted my Den PC. it showed up in Roon Control properly and played music. I next went to my Office PC and turned it on. The information on Roon Control audio settings changed to show the Office PC IP but the name in the Zone field still showed the Den Zone name. I pointed my Control app to this “Zone”.
When I tried to play music it started cycling through each track in a rapid and uncontrolled pace until it hit the end of the album. This took just a few seconds. This fast cycling was what I first experienced when I set up this new NUC for Audiolinux Bridge. The album(24/96) is “A la Russe” with Alexandre Kantarow. It is a FLAC album that is local, not Tidal.
It seems as if the Core server does not get updated properly from each Roon Bridge. It keeps old information, confuses or conflates information, and only seems to show one bridge at a time. These Roon bridge PCs have unique hostnames and static IPs. The Core PC runs ROCK and has a static IP.
Hi Dylan. Still waiting for some feedback.
Here is the latest on my end:
My system is:
Verizon G1100 FIOS router. IGMP is enabled. Due to living in an old house with preexisting coax runs I have to use MOCA adapters to the basement where my speaker system is and to our office where my headphone system is. Currently I have one Windows 10 Roon server in the basement with local SSD storage and Audiophile optimizer to simplify Windows. My speaker system is also in the basement and uses a fanless box running Audiolinux ramroot with no internal drives. My headphone system is using a NUC running Audiolinux headless in ramroot with no internal storage.
I should really say that this is what I want to do. My issue is that I can only seem to have one Roon Bridge available at a time. The last one to boot is the one that Roon shows. Both work perfectly and sound great when alone.
I have tried everything. If I am running Roon app on one of my other non-endpoint workstations the local outputs show as available. Regarding multicast and network/switch/router issues I tried setting all three devices up in my basement on a simple switch and running a 100 foot cable up to my router. My hope was to take MOCA out of the picture. That did not work either.
I have reinstall the OS on every box and read through very readme, FAQ, Doc and post I could find on CA, Piero’s Audiolinux site, and Roon Community. I have emailed Piero at AL. I even tried Roon Rock which gave the same results.
Previously I had Roon server running on Windows Server 2016 out through Dante to a Focusrite D16 and had Roon bridge running upstairs in my HP rig. That worked well but I really wanted to get Audiolinx running downstairs in my speaker system and use a separate server.
I am stumped. Any thoughts before I pull out my last hair?
One final question. Does each Roon Bridge installation produce a unique identifier that allows them to be distinguished apart by Roon or does Roon just go by IP or MAC address? This issue is acting as it the server cannot distinguish between the two installations even though they have unique hostnames and static IPs?
Pretty sure from my poking around they generate a GUID on first run and that’s what Roon uses under the hood. That’s why someone asked earlier in this thread if you had cloned the installation. If you search the forums here, I believe it’s been mentioned elsewhere how to find the file the GUID is stored in and delete it, at which point the Roon Bridge should regenerate it the next time it is restarted.
Thanks. I did not clone the installs as I do remember reading earlier about the GUID. I have done several fresh installs by now. I even downloaded a fresh file to be sure.
I will try to find those instructions.
BTW. This morning Audiolinux Support recommeded that I edit the “hosts” file also as I had changed the host names to be unique. I edited /etc/hosts to read “ audiolinuxD.localdomain audiolinuxD”
…which is different from my other box.
I rebooted the Core and restarted the AL Roon services on both bridges.
It did not make a difference. The Roon Core still confuses the two boxes. It even shows one under “Audio” and lists the other in “About”!
The GUID gets stored in a file in the Roon data directory. I don’t think reinstalling or even uninstalling really clears out the data directory. I just looked, and on my Linux Roon server, the bridge GUID appears to be in /var/roon/RAATServer/Settings/unique_id. It’s a text file with a GUID in it, so would be easy to compare between your separate installations.
One more piece of information. If Bridge A is showing in Roon Control and I unplug it’s ethernet cable then Bridge B shows up right away and ready to play music.
Maybe just tag @dylan in case he missed the follow up…
Thanks. I did that earlier today but have seen no reply.
The good news is that I got the answer from cwichura and from the developer of Audiolinux.
"RoonBridge generates and writes out a unique id into its data directory on first run and uses that to identify itself to RoonServer. Clear out /var/roon on the second device (or hunt down and delete the RAATServer/Settings/unique_id file) and it will generate itself a new one next time it starts up."
I deleted “unique_id” and rebooted.
Both Bridges show up as expected now. it is odd to me that Roon gave me no error regarding a duplicate identifier or that the install could even allow it.
I hope that someone will benefit from this information.
Thanks to those who offered suggestions.
Edit: to remove grumpy comment.
That’s basically what I was suggesting a few replies up in this thread…
Sorry. I was trying so many things that I overlooked your suggestion. Knowing that two files had the same ID would have been a big clue but I would have still needed to know that it was OK to delete the whole file. I have marked your post as the solution.
I do appreciate your taking time to reply.
I’ve no doubt it would have been pointed to, however, it’s highly improbable that GUID’s would clash so it’s not where I’d expect diagnosis would start. Only reason I asked is because I recently dealt with cloned partitions in a raid array. It’s highly probable to me that you cloned one install and used it on the second device, even though you may not remember doing so.
Your conclusion makes sense but I noted your earlier reply and was very careful to download independent copies to two separate and easily distinguishable USB sticks.
Anyway thanks to Community input and the persistence of Piero, the Audiolinux developer, the issue got resolved. Roon running on AudioLinux sounds pretty great and using a NUC gave the best sound to my ears. Bridge is running on ramroot(ramdisk) meaning I have no internal drives in my NUC or my other HDPlex fanless case. That is a pretty good cost savings and also a boost in sound quality.
Is this what could be called a conondrum?
Your initial post states clearly that you got one system up and running before doing an install on your second system yet both systems ended up with the same GUID. This should not be possible yet it happened.
Makes one wonder how the GUID is calculated!
It is possible that I goofed, as my first wife has pointed out that I am not perfect, but I really was aware that I needed to do a fresh install from a different stick to avoid issues. It is a head scratcher that ate up easily a dozen hours of my time.
I certainly feel more confident with the Linux command line now!
This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.