As per the title, whenever I forget to move Roon off of one of my secondary displays before shutting it down, Roon subsequently fails to start (please see system information and screenshot below).
The screenshot below shows Roon failing to start on display 4. Note though that it also fails to start on displays 2 and 1. I initially thought that the lower DPI of my smaller screen could be the culprit, but that proved to be a red herring.
To resolve this, I have to:
Kill Roon
Disconnect the display
Start Roon again - this will force it back to the main display, where it will successfully start.
If I forgot it in expanded mode, restoring the window will make the window disappear off-desktop. In this case I have to kill Roon again. upon restating Roon the second time around, the restored window will show up on my main display.
It would be fantastic if you could fix this bug, it is beyond frustrating. That being said, at least I don’t have to resort to re-installing Roon, as recommended in other threads.
Also, I’m pretty sure it’s not [the drivers]( Roon on Windows won’t start or crashes right at launch (roonlabs.com)) - they are up to date, and no other applications exhibit issues.
You have our apologies for the long delay in getting to your issue!
Could you please reproduce the issue and share a more specific date and time? Once you let me know this info, I’ll go ahead and enable diagnostics for your account so I can review the logging for clues.
If you’d rather do it yourself manually, please use the directions found here and send over a set of logs to our File Uploader.
I have uploaded the logs to the Logs Upload Server:
The name under which the logs were uploaded is cata
The client log archives are prefixed with cata-2024-01-09-Client
The server log archives are prefixed with cata-2024-01-09-Server
I reproduced the issue twice at around 2:47 PM HST on January 9th, 2024.
Please note that today I was only able to reproduce the issue when Roon was maximized on the secondary display.
I was able to reproduce the issue with a non-maximized Roon window when I posted my original report.
Thank you for looking into this, it is greatly appreciated! I hope this additional information is useful.
Do let me know if there is any more info I can provide
Thanks for sending those over! Oddly enough, the logs don’t cover the time you’ve shared above. If possible, getting a copy of the windows event viewer log may be of better help - steps to follow below:
Press Win + R and type eventvwr.msc
Press OK – this should open Event Viewer window
From the left sidebar go to Windows Logs > Application
Right click on the Application subsection and pick Filter Current Log... from the context menu
Thanks for sharing the above! Do you by chance use any third-party software that improves GPU performances or helps to maintain your setup? There unfortunately wasn’t much useful information shared in the event viewer logs, but we could be seeing this issue relate to your GPU or its drivers.
Nope, it’s all very vanilla - I have the latest drivers from NVidia (via GeForce Experience, which has all game optimization, overlays and the like disabled), and that’s that:
Well, I’ve reinstalled NVidia drivers - they now only offer them through GeForce Experience - and switched to Studio Drivers, to see if it makes a difference.
Alas, it does not.
I’ve also tried to reproduce the issue on my laptop, by connecting it to a second monitor - and failed. So you are prolly onto something when you think drivers/sw/hw environment. Still, every other application works without a hitch on the system…
Is there anything else I can do to give you more information?
The computer on which I can reproduce the issue has 4 monitors, out of which one is a pen display. Still, Roon does run initially on any of these displays, and only hands when trying to re-start on a secondary monitor in maximized mode.
I would even be cool with a workaround like running Roon through a script that deletes the windows position that Roon appears to remember - so that it restarts on the mani display - I can move it afterwards. Can you share where Roon stores these settings? I could monitor registry/files, but if you have the info handy I’ll take it
renaming (or deleting) saved_window_pos allows Roon to start.
As expected, upon deleting/renaming saved_window_pos, Roon starts on the primary monitor, with the default (OS-assigned) window size and position
A system restart is not required to allow Roon to start after renaming/deleting saved_window_pos
Once Roon starts, moving it to a secondary monitor, maximizing the window, and then closing and re-starting Roon continues to reproduce issue, in that Roon hangs trying to start on the secondary monitor.
killing Roon, renaming/deleting saved_window_pos, and then starting Roon again allows Roon to start (on the primary monitor)
The content of (one of) the saved_window_pos for which Roon hangs is M1208,2200,1536,864
the semantics appear to be M, denoting “maximized”, followed be the position and size of the last non-maximized Roon window.
Here are some additional observations I’ve made while trying to tease out how Roon uses saved_window_pos, and where things go wrong:
Roon modifies the content of the file as the Roon window is moved/maximized/restored
On the affected system:
If the Roon window is on either my secondary left-hand-side monitor or my secondary bottom monitor (see original desktop pic) and it is not maximized, closing and restarting Roon will cause it to start on the primary monitor and not honor the stored window position. For example:
if the Roon window happened to be on my left-hand-side monitor when closing Roon, saved_window_pos would contain something like -2848,347,1536,864
if the Roon window happened to be on my bottom secondary monitor when closing Roon, saved_window_pos would contain something like 1112,2211,1536,864
upon restarting Roon:
The window coordinates are not be honored
Roon starts on the primary monitor, and saved_window_pos is updated to something
like190,190,1536,864
if the Roon window is on the right-hand-side secondary monitor and it is not maximized, closing and restarting Roon will cause it to start on the secondary monitor and hang. For example:
saved_window_pos would contain something like 4464,354,1536,864
upon restarting Roon:
Roon honors the stored window coordinates
Roon starts on the right-hand-side secondary monitor, and hangs.
The content of saved_window_pos does not change.
if the Roon window is on any secondary monitor and it is maximized, closing and restarting Roon will cause it to start on the secondary monitor and hang. For example:
if the Roon window happened to be on my left-hand-side monitor when closing Roon, saved_window_pos would contain something like M-3490,365,1536,864
note that assuming that negative coordinates are the culprit is a red herring - the same behavior occurs on all the other secondary displays (where all coordinates are positive).
upon restarting Roon:
Roon honors the stored window coordinates
Roon starts maximized on the secondary monitor, and hangs.
The content of saved_window_pos does not change.
While I would very much like to see this behavior fixed, I can live with a workaround - it’s trivial to start Roon through a script that first deletes saved_window_pos - much better than disconnecting monitors and the like, even if this means that Roon will not retain my preferred placement on the desktop
I’m one of the developers on the Roon client team, and am following up on this. Thanks for the detailed report and explanation, we always appreciate it.
Can you explain how you came to understand that this is red herring?
The reason I came to believe the lower DPI display hypothesis may be a red herring is because I am able to reproduce the issue on the two secondary displays (to the left and right of the primary display) that are identical to the primary display, and identically configured (same display resolution, scaling, color space, etc). I was able to reproduce the issue both with and without the lower DPI display connected.
For completeness, here are the current display configurations:
I thought for some reason that displays 1 and 2 were smaller than the primary one, but I think I must have hallucinated that somehow, probably by taking stats for display 4 as also applying to 1 and 2.
@ben - I was wondering if you have any updates on this, and whether more info is needed.
I understand addressing this kind of issues takes time, so I am mostly replying to keep the topic alive
There aren’t any new updates to share, but the ticket is in the queue and has been selected for work from our development team. Luckily we don’t need any additional information - I will certainly keep you up to date as things progress, and very much appreciate your continued patience here.
Do you use any remote desktop/control software on this machine? Stuff like VNC, Teamviewer, Remote Desktop, etc? I’m thinking about anything that might be creating virtual screens.
If you’re up for it, I’d love to figure out where Roon is hanging.
