From 0 to NUC/AL/RAM in 2 hours

[austinpop]

Epic and brilliant post! A true service to the community.

 

Thank you - and bravo!

 

👏

 

P.S. "just the right amount of coffee" -

[austinpop]

9 minutes ago, One and a half said:

One possible ask is from @computeraudiophile to allow edits as time goes on

 

I am pretty sure, although not 100% - so it would be good if @The Computer Audiophile confirmed - that the OP post can be edited in perpetuity, i.e. there is no time limited edit window.

[austinpop]

1 hour ago, TheAttorney said:

2. How is the NUC endpoint recognised across the network by the Roon server? Does it have a static IP address?

The microRendu does not have a static IP address, which means I'm forced to use a router to dynamically allocate an IP address - which for various reasons is a PITA in my particular situation.

 

Roon does not need the Server or the Bridge on the endpoint to have static IP addresses. As Bob said, all Roon components advertise their presence on the network, so get discovered automatically.

 

If you like, you can certainly set your server, endpoint or both boxes to static IP addresses. I've always done this manually, and I noticed AL does not have a menu option to do this, which shouldn't be a big deal to implement. I've asked Piero to consider doing so.

[austinpop]

4 hours ago, TheAttorney said:

Thank you Bob and Rajiv.

 

But there's still something I'm missing here regarding IP addresses. You make it sound as if Roon server just automatically finds its endpoint. But I think it can only make that discovery if the end point has an IP address allocated to it - either statically or dynamically by a DHCP server.

 

OK you lost me, because this is exactly how Roon works! The endpoint has to have an IP address on the same subnet as the Roon Core. For Roon to work, each of these machines has to have its own IP address:

• Roon Core (aka Roonserver)
• Roon Bridge (aka endpoint)
• Roon control app (if running on an iDevice or other system)

Once both the Roon Core and the Roon Bridge applications are up and running, they become visible to each other and the control app.

 

4 hours ago, TheAttorney said:

In my case of W10 laptop server bridging ethernet to wifi, with a wifi-connected router,  that bridging process is fiddly and unreliable. It sounds as if the same will apply to a NUC end point. I can live with that, but a static IP address would mean that Roon server could find its endpoint without the wifi router being involved - which removes a level of complication at start up time.

 

 

Perhaps you can describe your network topology? Which machines are running Roon Core and Roon Bridge? How are they connected?

[austinpop]

26 minutes ago, TheAttorney said:

My system is a direct line of Roon Server on W10 laptop > Anker USB/Ethernet dongle > ethernet cable > Roon Ready mR > ISORegen > DAVE.

 

The router (with internet access) is in a different room and all connections to it are via wifi. There are no switches involved anywhere.

 

The laptop’s touchscreen & keyboard controls Roon (but I can additionally control it from my  smartphone via wifi if I want to). I use Windows to bridge ethernet to wifi within my laptop.

I find that setup very convenient for my circumstance, but occasionally the bridging fails on server start-up , which causes Roon server to not find its end point on the mR. So I have to go through a ritual to get things working again.

 

That ritual was tolerable, but has recently become almost farcical after moving house with a new broadband supplier with their dedicated router. I simply cannot get bridging to work with the new router – everything looks properly bridged, but the mR cannot be seen by Roon server (or even seen on the network by the new router).  So I use my old router to do the bridging, then I can switch off the old router and bridging continues for a couple of days until, presumably, the dynamic IP lease runs out (or I restart my laptop).

 

But then I wanted to try the free Qobuz trial with Roon intergration, so I needed internet access via the new router. I was somewhat surprised to find I could bridge using the old router, then connect to the new router – and amazingly the bridge still held whilst giving me access to Qobuz. I could even put the old router away for couple of days – until the lease ran out. But this clearly can’t continue like this.

 

There are probably a dozen ways to handle such networking/bridging issues, but the simplest solution to my mind would be if the end point had a static IP address. But I don’t want to unduly divert this thread by discussing network issues – the key NUC-related point here is that audiolinux currently has no option to set a static IP address, so therefore it will be no better than my current mR in handling my particular network/bridging situation.        

 

 

Yes, sounds like you have some networking issues going on.

1. Router issues:
   • One thing I always check, especially with the crappy routers ISPs provide, is whether UPNP and multicast are enabled. Usually you can go into the router's web UI and find these. Ensure they are enabled. Instead of multicast, you may see the option called IGMP. Anyway, when these are off, they can impede discovery, so turn them on.
   • My preference is to have the ISP to just give me a modem (or supply my own) and set it in "passthrough" mode. Then you can use a "good" router of your own choosing. Not sure if UK ISPs offer this option.
2. Bridging issues: as has been reported from day 1 on the novel thread, bridging sometimes doesn't work on Windows 10. Not sure why, but probably due to driver issues. I remember several people (myself included) found relief by adding a 3rd network adapter to the bridge, even if it was not connected. You could try switching to a different dongle (check the chipset). I think on my machine, the Anker (with the Realtek chipset) worked well, but I had to add a 3rd adapter (wifi) to the bridge. In your case, you could just add another Ethernet dongle, add it to the bridge, but just leave it unconnected.
3. Static IP: Finally, if you do feel static IP addresses are necessary, you can definitely do static IP on AL. See http://www.audio-linux.com/#GUIDE and search for "static address" within the page. I asked Piero about adding a simple menu option for non-geeks to do this, and he said it will come out in version 105.

[austinpop]

1 minute ago, lpost said:

I've got to disagree that enabling uPNP on the route is a good idea.  It opens the opportunity for any malicious software to be able to open outbound connections to command-control hosts.

 

Multicast/IGMP proxy yes, it will often help Roon communications but uPNP, no.

 

You may be right. I first ran into the UPNP issue years ago when I was running minimServer, so it may well be unnecessary on Roon. I just set it on for consistency, but didn’t consider there may be a security risk.

 

Thanks for the warning.

[austinpop]

@TheAttorney

 

@hifi25nl just added a menu-driven way to set static IP to the latest Audiolinux menu version 105. So if you need it, it's there.

[austinpop]

1 hour ago, lpost said:

Nope, still just says AudioLinux menu - Version (with nothing where I would expect a version number).  No big deal.  I'm happy with the system as it stands, plus my few other tweaks to disable other unneeded services.  No plans to update until something major comes along...

 

A full update is 3 things: the kernel, all other packages, and the AL menu. I would update all 3, in that order. First, reboot without ramroot mode. Then update kernel, reboot again. Then update all other packages. Finally, update AL menu. For good measure, reboot again, and then check the menu. It should be there:

[austinpop]

12 minutes ago, lpost said:

 

Thanks, I didn't realize all 3 are required.  I asked Piero about the recent kernel updates and he told me there was very little fixed and if I wasn't suffering with any issue best to leave it be.  

 

AL is moving so fast, I should probably step off the train before it leaves the town I'm enjoying quite a lot right now.

 

I'm not strictly sure what the dependencies are. This is one of the drawbacks of AL and this fragmented approach of updates. What would be more comforting is to go from one known working bundle of (kernel, packages, AL menu) to a new working bundle. This is what more mature systems do. AL is still definitely bleeding edge.