In some recent build it was completely broken to change a recording date of a multi-selection of tracks. In 952 it is possible again, but still buggy. This is with Windows remote (did not try on my Android tablet):
Multi-select several tracks of an album
Click the album’s three dot menu > Edit > EDIT TRACKS
Scroll down to Recording Start Date
Click into Year, try to enter 4 digits
→ It does not work, you can only enter 3 digits
Click into Month and enter a number
Click into Year again, now you can enter a 4th digit
Same with Recording End Date.
The tab key to jump from Year to Month to Day is not working either
Support will probably want a new ticket in the Support section with the appropriate form filled out. The way to get support’s attention is to preface the tag ‘support’ (no quotes) with an @ sign.
Room is still crashing randomly on my windows 11 PC.
It used to be perfect, never a single problem over the years and since the latest 2-3 builds it started crashing.
Even if it’s not used, sometimes I’ll try to start playing something from the remote only to find out Roon isnt opened anymore on my PC, it just crashed while doing nothing…
I don’t think I’ve experienced a Roon update with this many critical issues before. Remotes crash constantly (IOS, Windows etc) The Windows remote is the worst actually and I’ve never had issues with it before. As well the Nucleus+ core needs to be rebooted pretty constantly at every 12 hours or less - perhaps related to the memory leak issues others are recording above.
As noted elsewhere (IIRC), an apparent MEMORY LEAK problem with the macOS Remote app:
I’ve been running B952 for 5+ days now, and the only problem I’ve had is with the macOS Remote app (MacBook Pro i9 running macOS 11.6.6 with 16 GB RAM)… Monitoring my Mac’s RAM usage via Activity Monitor reveals that the Roon remote app uses ~340 MB of RAM at startup, but over maybe 12 hours, that increases to over 1 GB. At least in my case, each time the RAM usage goes over 1 GB (the last time I noticed, it had reached 1.25 GB), the remote app becomes unresponsive when attempting to display new content / screens. Switching to another screen such as Genres, Qobuz, etc., and/or back to Home, and I end up watching the animated logo for at least a minute or two before the screen loads/displays, though playback is never interrupted.
During these macOS Remote app hangs, I can access the Nucleus via either of my iOS Remote apps and everything is still running smoothly (quickly). Quitting the macOS app and then re-opening it immediately resolves the problem – at least for another 10-12 hours!
My Nucleus (Rev B) has not had any problems or restarts since the update, and as noted above, no problems with the iOS remote apps. I’ve never had this problem with previous builds, and used to be able to leave the Mac remote app open for days on end without any problems. Hopefully @support has this in their queue and a fix will be included in the next release. I know, minor 1st world problem, but thought I’d add my 2¢.
Logging in and posting for the first time in a while that I am seeing inconsistent behavior from iOS remotes as well as high resource utilization on my Ubuntu core. That 4th core below is being pegged at 100% which is unusual. I logged in earlier today and my system load was over 2.0. This is a machine dedicated to roon.
After several reboots to be certain, I am now having the occasional very slow response times populating the Home screen on two Android and two Win10 remotes. I haven’t had this issue with any prior build.
It’s been a longstanding issue (months or even years) with the Mac app, not just with this release. I’ve noticed that memory consumption slows down a lot if you close the window without quitting the app entirely, and the app will reopen instantly with no delay.
It also consumes 4-7% CPU continuously on my 2019 MacBook Pro, which is a lot for a remote app that should be doing very little processing and only updating UI.
Not sure what’s up, but my core on my Sonic Transporter keeps just restarting out of the blue in the middle of a song. This never happened before the most recent update. Hopefully a fix is on the way. Thanks.
Thanks for the tip! I didn’t have time to reply last night, but tried your suggestion of just closing the remote app window, and then a quick & easy reopen (OPT-CMD-1 key sequence on Macs) when wanting to view the window for playback, etc. again. None, or very minimal, RAM increase even though the app was still open / loaded in memory for 12+ hours. A good workaround until ‘the team’ delivers a fix.
I was watching memory usage today, and I found that I got the same benefit by simply minimizing the Roon window (more intuitive for a user than closing it).
After launching Roon Remote on my Mac and immediately minimizing the window, the memory usage stabilized at around 325MB. When I reopened the window, the memory jumped up immediately to 650MB, then leveled out around 500MB. Then I browsed the Qobuz library, queued up a couple of albums, started play and minimized the window, and the memory usage remained very stable around 600MB. At times I saw the memory rise temporarily (up to 660MB) but it would drop back down to about 600MB. When I was leaving the window open, it would steadily rise up to 2 GB or higher.
My suggestion for Mac users is to keep the Roon window minimized whenever you are not actively interacting with it (use Command-M or click on the window’s yellow button).
