The periodic need to reboot a roon server is getting a bit out of hand. Running Linux (Debian 12) dedicated to roon (on one of the NUC models that was listed as supported) with OS/App on NVMe and music files on local SSD (periodically refreshed by rsync push from NAS). It sees periodic OS/package updates, along with a reboot to ensure stable state. Seems that if nothing is played for a day (sometimes a couple days), the next time it’s used - it’s showing an error message about the database needs to be restored. Comically (or tragically) enough, finally decided to try restoring the database instead of simply rebooting. What was the result of that effort? No improvement and having every client bark about the server having ‘changed’. Have found that if Roon is left streaming music to a destination, that this will prolong the time between these events - but doesn’t stop them from happening.
This is becoming rather synonymous with other issues: the metadata improver which seems to remain in a constant “paused” state -or- after a reboot, searches from the main page fail for an hour+ with “Can’t connect to roon search” (simple “exact match” or “and” logic searches should be available at all times for common fields: artist, album, genre, album artist, year, track). Makes for a less than stellar experience. Rather problematic when a guest asks to hear something on the system which is impacted by this and their question is basically: Given everything, why do you still use something that doesn’t ‘simply just work’ all the time? While trying to go “cloud” may be interesting [for some], it’s not helpful if the product’s behavior is erratic or non-viable for long periods.
When first trying roon (<v1.8), was not only amazed but felt that roon was an ‘end all, be all’ for any music collection. It seemingly had everything (even if a bit quirky for some aspects, but could easily look past those given everything else) and was rock solid. It’s because of that experience that issues over the past couple of years have been given some latitude. Can one make an argument for the Roon ROCK Server/Nucleus - sure. However when last checked it did not support [configurable] NTP for time sync, nor rsync [not pull, but push via module for automation] for replicating data to it - so that media is from local disk. By avoiding disk sharing, it means when maintenance/service is performed on the NAS there is no interruption to music listening (SSD/NVMe is sufficiently cheap to enjoy this option).
However, the latitude gleaned from such a positive [previous] experience grows thin given TCO with a sense of approaching more years with agitations vs. simply enjoying. At this point, every time music listening session now needs to be “scheduled”. 1-2 hours prior, check to see if Roon server needs to be rebooted and to provide sufficient time for the search on the main page to become “usable” again. Sadly, the ability to listen to local music is now more consistently available via Apple Music for immediate listening pleasure. Starting to question alternatives. It’s a very simple ROI: if the pleasure of listening to music is derived as expected, then the TCO is justified.
As others point out, when something starts to feel like there’s too much agitation vs. simply being able to enjoy it - it will eventually be replaced. Fancy features, ‘cloud’, remote access, may be great, but those become immaterial if local media is not available. When others experience these issues after they transitioned to it as a result one’s praise for the product, it simply doesn’t bode well and may diminish consideration(s) of future recommendations.
Hoping that roon will address such issues in the near future.
