[quote=“Ed_Cohen, post:8, topic:14920, full:true”]
What I would like to have is the Windows 10 PC be able to play music remotely via a phone, iPad etc. [/quote] Roon Server is supposed to support both Control and Output functions, according to the Roon architecture. Most of us are using Output Zones distributed over the network, so we don’t need to be constantly logged in to the server. However, it would appear that directly connected output devices fall prey to this “must be logged in” snafu.
I’m flagging @support here to see if they can suggest a better workaround for your situation than the auto-logon trick I suggested earlier.
Some of the Roon endpoints are on PCs, which also act as Control devices for Roon. And there’s the rub, when I’m using a PC as a Roon Endpoint (in addition to it being a Control), I’m logged in to it.
What you could try is to download the Roon Bridge software to your extra server, and see if that will work as an endpoint without your having to be logged in?
Edit: or even try installing Roon Bridge onto your Core server, to see if that will work?
Hey @Ed_Cohen – Roon installs to the user’s App Data directory which, among other reasons, gives us a lot more flexibility for how we update.
This is done specifically with setups like yours in mind, so you’re able to click a button on any device in the house and your Core can update, as opposed to requiring that you log in remotely and give permission to the update directly on the Core machine.
This also means is that Roon requires the user is logged in to run. If you don’t intend to connect a monitor or keyboard to this machine, you’ll just need to configure Windows to log in automatically, and you’ll need to configure Roon to run at startup.
@Paul_Chatfield - it was done using Grapholite. Think of it as a poor man’s Visio - it works in pretty much the same way, but is orders of magnitude cheaper. It’s also supposed to be able to import Visio files, but that doesn’t work for me. It may be because my Visio dates from the 2003 version. New diagrams I create, I use Grapholite (the Windows 10 App version); and I just keep Visio around to maintain the old ones.
@mike - thanks for your reply. So my auto-logon trick is the way to go. Good to know for future reference. Perhaps I should write up something about this situation for the KB?
@Ed_Cohen - so I’ve tested the Auto-logon approach on my headless server (an Intel NUC), and it works, but there are a couple of things to bear in mind:
1 - the setup instructions in that link I posted earlier are slightly different if you’re setting up your Auto-logon via a Remote Desktop session. Once done, and your server rebooted, it does indeed perform an auto logon, and you can set up your directly-connected endpoint in Roon and use it.
2 - However, if you ever start a Remote Desktop session to your server for whatever reason, this will break your Roon endpoint. You will need to restart your server to restore the endpoint again. Roon remembers the setup information for the endpoint, so it should automatically appear once the server is restarted.
Re (1):
in step 3 of that link, via a Remote Desktop session, the “Users must enter a user name and password to use this computer” checkbox is already unchecked, and if you click Enter, as the instructions say, the window is closed. You need to first check, and then uncheck, that box. Then you will see that the Apply button (which was greyed out) is now selectable:
Complete this, close the windows (by clicking the ‘OK’ buttons), reboot the server, and you’re all set to define your directly-connected audio devices in Roon.
While not a windows issue, a headless macmini with no display connected will not show USB connected devices, without running a display faker app or a dummy HDMI/VGA/DVI type adapter - I think I posted this elsewhere too
Hey @Geoff_Coupe – we took a look and I think the issue here is Remote Desktop. When you log in remotely, it basically passes control of the local devices to the remote computer, and from Roon’s perspective, the audio devices just disappear.
Remote Desktop is also known to cause issues with OpenGL (which may or may not be an issue for a headless setup) but point being, it tends to provide remote access in a pretty heavyweight way.
For what it’s worth, I use Team Viewer quite a bit, and haven’t seen anything like this.
@Ed_Cohen – let us know how you’re getting on here, ok? Thanks guys!
@mike - yes, indeed this is what happens. The bummer is that when the Remote Desktop session is closed, Roon can’t grab the devices back. That’s why I said that a reboot is necessary.
I have it working the way you described… Basically I have a PC that auto logs in and I can remote into it when I need to update it. Then I restart the machine and everything comes back the way it should…
I use Teamviewer all the time. You can get into an issue with your graphic drivers and Teamviewer, but generally it plays nicer than Remote Desktop in every way.
I am in the middle of setting up a Roon/HQPlayer demo unit to try and test DSD512 with a T+A DAC8DSD dac. Currently, I have the computer to auto-login to Win10, Teamviewer, RoonServer and HQPlayer and the local Wifi network setup with my phone’s hotspot functionality. As of now. I turn on the hotspot, turn on the pc, wait a bit and I can start using Roon on the phone directly to the stand alone. I have Teamviewer avaialble if I need to see the desktop and I’ve pre-loaded the T+A drivers. Deciding now, whether to add a NVIDIA card in or chance that the i7 4790 will have the horsepower to do DSD512. Can’t test it at home and there are other people from Computer Audiophile forums who might be meeting up with me to do the listening and I don’t want to waste their time if it goes south.
There are a couple of things that can be done here. First off, you want to be sure that remote desktop isn’t redirecting audio to the client (viewer). This is an option on the client. On the Mac RDP client you select “Sound: Play on Device” in the redirection settings.
This fixes issues during the session, but once you close the session it goes into a limbo state where it isn’t connected to anything (and therefore no devices). If you close the session by either closing the client or selecting “Disconnect” on the host PC then you’re stuck. You can, however, close the session by redirecting it back to the console and for this you need to use the command line.
Open up a comand window and enter:
query session
This will return a list of all of the currently active remote desktop sessions. If you look in the ID column it will give you the Session ID number. Find the one for your current session (likely 1 or 2). Then:
Say, for instance, your session ID is 2. You would enter:
tscon.exe 2 /dest:console
That will disconnect your current session and re-connect it to the console (at which point it will have access to all of the system devices)
At one point I wrote a batch file to automate the discovery of the Session ID and then feed that value to the tscon command, but I’ve since lost it.
Ultimately, I found it easier in the long run to use VNC to connect to the machines which need to interact with local audio or HID devices. TeamViewer and Splashtop work equally well, but I prefer the light footprint of VNC for local control.
I am using Server 2012r2 with HyperV, Roon server was on the host originally but that was flaky at best, so built up a dedicated VM to run as the roon server, as soon as I tell it to log off it kills roon. Is there NO way to run this as a background service and not an App?
