· I am experiencing freezes or crashes
· I am experiencing freezes or crashes
· Other
Playlist search on Nucleus Titan takes forever and crashes; same operation on base Mac mini works, takes seconds
Full UniFi network, switches, router
Hello @David_Nanian,
We’ve enabled diagnostics for your device, but it appears to be offline at the moment. Once it comes back online, we’ll receive the diagnostic information and review the logs.
In the meantime, could you please provide the name of the playlist and a timestamp for when the issue occurred? This will help us pinpoint the problem more efficiently.
Kind regards,
Vadim
It’s offline because I moved to the mini for the moment since the Titan was working so poorly. I can readily move back, of course, and will do so shortly.
The playlist is “Vlad’s Jazz Playlist”. I don’t have a timestamp, but could easily reproduce the issue. Note that it will cause the server to crash; would that be acceptable within the context of “diagnostics”, or would they not be uploaded?
Can I also ask: should I expect the performance of your top of the line Nucleus Titan, on the same network, using the same sources, attached to the same switch, be better than that of a lowest-configuration, entry-level, headless Mac mini?
I’m a bit confused. I moved my license (via login, of course) over to the mini (which required deauthorizing the Nucleus Titan, which I did).
I just brought the NT back up, and logged in. It did not prompt me for an authorization. It is giving me an error that it cannot verify its connection with “our servers” and so the Metadata Improver has been paused; perhaps that’s due to your debugging?
Anyway, it’ll take some time for the initial re-onboarding/sync to complete, at which point I will do the search and provide you with a timestamp.
OK. It finally finished the initial scan (note that I’m still getting the Metadata connection error, despite restarting the NT again), and I started loading the playlist at 12:21pm. I then proceeded to do the search, in the artist column, for “Art Pepper”.
And of course, despite this failing over and over and over in my previous tests, including going back and forth between the two setups multiple times, it only took two minutes this time and did not crash.
At 12:25, I clicked “Reset” to clear the search, then searched on “Intensity” for the Album. That took about a minute to fail with no matches.
I then went to the Services and asked both Tidal and Qobuz to sync. Nothing seemed to happen. I went to the Qobuz “New Releases” section, and received (after an extensive delay) “No results”. I tried the same with Tidal, and got “error loading page”.
I’ve verified my network and it’s fine, so I’m not sure whether the problems I’m seeing with the Titan right now is because of your debugging, since none of these errors were happening before, whereas the previous errors are not occurring…but I know that there are additional albums I added while I was on the mini for a day or two (Qobuz) and they have not appeared.
So, I logged out of the Titan and I’ve logged back in. This time I got the expected authorization page (curious) and I’ll wait for everything to sync and then try again.
(As a progress report, the startup and onboarding is working much more normally this time, including adding the LPs I added while on the mini during the process; perhaps your debugging will also tell you what the heck was going on last time as well. It’ll be a while until this completes. Also note that at 12:58 [as well as a number of times before], I’ve received errors like the ROON app can’t reach the server, and then it recovers, something that I’ve seen when the server stops responding, as far as I can tell, and then it recovers; it hasn’t crashed.)
OK. Finally finished logging in and indexing atgain around 2:50pm.
Opened playlist at 2:51, started search for Art Pepper as before once it came up. Roon logo animation very erratic, goes into slow motion and stops often. And yet, it came up about a minute later. Did a Reset, and here’s where it starts getting bizarre; save for the extensive amount of time it took to complete the initial log in; first it animated progress for a minute or two - then I got a “waiting for server” with a progress circle briefly, then it went back to the progress logo animation, did “waiting for server” again at 3:05, animated again, and the playlist still hasn’t shown up at 3:14.
That’s right, > 20 minutes after clicking “Reset” the playlist isn’t back.
I’ll follow up again when it finally does with an “it’s done” timestamp, but this is clearly unreasonable.
Another “Waiting for server” at 3:19, followed by “Uh-oh, something’s not right”, which suggests the server crashed. Went back to a “full screen” progress animation about 30 seconds later, and I’ve verified that the server did, indeed, crash:
Operating System
Version 2.1 (build 271) production
Running 3 hours, 59 minutes, 7 seconds.Roon Labs Software
Version 1.0 (build 18) production.
Running 3 hours, 59 minutes, 3 seconds.Roon Server Software
Version 2.48 (build 1517) production
Running 0 minutes, 37 seconds.
The waiting continues.
And at 3:25, after it crashed, came back up, full-screen animated, drew the bottom bar and is re-onboarding from the reboot, I got a “There was an error loading your playlist (NotFound)”, which, of course, is not true…the playlist is there, but it’s lost track of it in the main window.
I then got a “Waiting for server” animation at 3:26. I clicked the playlist in the sidebar at 3:27, and it came up (same playlist). I tapped the magnifying glass and started to type “Intensity”, got to “Waiting for server”, then the playlist came up with "Album filtered by “I” at 3:28. I clicked the magnifying glass again and typed “Intensity”, It came up at 3:30 with no match (correct), and I clicked “Reset”. That came up at 3:31. Tapped Artist magnifying glass again and typed "Art Pepper.
That came up at 3:33. Tapped “Reset”, Came up at 3:34. Tried “Intensity” again.got a “Waiting for server” animation at 3:37, again at 3:39, and frankly I got bored staring at it for this email at 3:45. I’m sure it’s going to do another “huge long wait followed by a crash and reboot”, which is obviously not a good result.
I hope you have sufficient material for a diagnosis and fix.
It crashed again at 3:52.
Hi @David_Nanian,
Thank you for the extensive troubleshooting and feedback, as well as your patience!
Based on a fresh diagnostic report from your Titan, the issues you experience could very well be due to a lack of RAM on the machine, we’re seeing out of memory errors causing Roon Server to crash:
(none) user.warn kernel: [ 5324.012171] oom_kill_process+0xf3/0x180
(none) user.warn kernel: [ 5324.012175] out_of_memory+0x10a/0x580
For a next step in testing to prove this is the core issue you’re experiencing, can you please test out using a fresh database with a smaller subset of your local library? Perhaps around 50% of your total tracks, and test if you run into the same issue?
Thank you!
I do not run into this issue when using a base mac Mini. And as you can see in the test results above, things are rather inconsistent, which leads me to believe (as a fellow developer) that an idle system with a large database should be able to handle a basic search and/or reset of a previous search of a playlist, no?
Seriously - let’s say I eliminate all my tracks and then it works. What does that tell us if you already know you’re running out of memory? Because, certainly, a solution of “well, to work around this, eliminate your music library” does not seem like a good one.
If there’s a bug in memory handling, garbage collection, or basic operation, we have a pretty clear case and setup to reproduce that, without eliminating the music library. We already know it’s happening, no? But why inconsistently? That says “bad memory management” to me…maybe even a leak. Who knows. The number of tracks in the library itself is actually consistent. The operation of Roon is not.
And if the problem is that the Titan is memory starved in its as-shipped, top-end, multi-thosand-dollar configuration, that seems like it’s under-spec’ed if it can’t perform a pretty basic operation outside the actual music library (because the playlist is external—a friend’s—that I search so I know not to recommend something he already has).
Note that I checked the RoonAppliance application on macOS, and it seems clear you’ve limited its memory use to 8GB. So, both the Nucleus and mini are effectively running in the same memory environment…so, why would one work and the other…not?
Hi @David_Nanian ,
I took a look over your Roon logs again and I noticed that when the OOM issue happens, there was a mention of an Unfolded Circle extension detected. Just to rule out extensions as a possible cause here, have you been able to reproduce the issue with all extensions disabled? Also, just to ensure that the Nucleus Operating System is in a fresh state, can you please try to perform an OS reinstall and see if this changes anything with regard to the issue? It shouldn’t affect your database, but it is suggested to make a Backup beforehand just as a precautionary measure.
The same exact extensions are enabled for the mini, which is not crashing. On top of that, the extensions are to control playback, and no playback is occurring - we’re talking about boot, waiting for onboarding/checking, then doing a basic playlist search.
While I can reinstall the OS, what theory is there about it being damaged? Isn’t it an entirely separate volume that, you’d think, wouldn’t corrupt by “running out of memory during a specific operation”.
Have you folks tried reproducing the case in-house?
Hi @David_Nanian ,
While there is one OOM noted in your recent logs, I did notice that RoonServer had a status of Not Responding in several other instances. The reason for us suggesting the OS reinstall is to ensure that the operating system is in a fresh state.
Looking over the timestamps of the Not Responding traces, it appears that the extension is one of the last lines recording in logging, so if you can try to disable the extensions as a temporary test, I am hoping that it would provide some useful diagnostic data.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.