Right. What does the next tab over look like? (DHCP Reservation)
@DDPS - thanks. I wasn’t able to edit the names in the DHCP Client tab (only ‘DHCP Reservation’), though…
And I now have both in Roon:
Great. And fyi, you can refer to those by name rather than IP address anywhere on your network now. as in: \\MacStudioEthernet\RoonBackups.
That way, if you ever get a new device or want to point to a new location, you don’t have to touch any end-user software; you just update the mapping there in your router software.
Many thanks, again, @DDPS!
Should I be doing that (name not IP address) in Roon’s Settings > Backup > Select Folder > ‘Choose Folder to backup to’ etc?
I see. Yes. Of course.
Would you expect that page in the Synology RT6600ax SRM only to allow edits (in this case to change names) in the ‘DHCP Reservation’ tab?
Yes, and that is the sort of thing I do as well!
Yes.
Great. Thanks, @DDPS; have changed.
The issue remains, though, of how to get Roon to recover properly/gracefully when there are the sorts of failures referred to throughout this thread.
I know that @benjamin and @vadim are working on that.
Your guidance and directions here will surely eliminate one part of the faults. Much appreciated!
Hey @Mark_Sealey,
Thanks for all the additional information, and thank you @DDPS for the additional assistance here!
Mark, we were able to review another fresh set of Nucleus, which were genuinely illuminating, so let me share what we found.
One coverage note up front: this set begins on July 12, essentially the minute before your power-pull, so the July 11 event and the July 12 morning failures fall just before the window. But we captured the July 12 wedge and your recovery in full, and that turned out to be exactly what we needed.
We finally have the mechanism behind the “only a cable-pull fixes it” behavior.
Between 14:09 and 14:11 PDT, RoonOS tried to relaunch Roon Server around a dozen times, and every attempt failed the same way:
A prior Roon Server process had wedged without releasing its lock file (Error: Could not create required lock file…Error: Already running. Exiting.
/tmp/.rnsems0-). Once that happens, every restart, including a web-UI "Reboot/Power Off" collides with the stale lock and exits instantly, because the OS still thinks an instance is running. That's why the softer restarts never brought it back and only pulling power did: a full hardware power cycle is the only thing that clears that lock and kills the stuck process. So your instinct all along was correct, and this also explains the "Another backup has already started" errors, same wedged-process, same stale lock.
The good news: since your 14:15 PDT power cycle on the 12th, the fresh boot acquired its lock cleanly and Titan has now run five days straight with no crashes, no lock failures, and backups completing normally. That’s the longest clean stretch we can see.
Two cleanup items worth doing while things are stable:
- Consolidate your backup share. Roon currently has several overlapping backup targets saved, the old
\\192.168.0.210, a\\192.168.0.198, your new\\MacStudioEthernet, and a\\MarksMacStudioWiFione. The single scheduled backup that failed in this window (July 15, 14:01 PDT,QuotaExceeded) was pointed at the WiFi share, which is the unstable one DDPS flagged. I'd remove every backup location in Settings → Backups except\\MacStudioEthernet\RoonBackups, and repoint the scheduled job there too. That eliminates both the WiFi-address instability and the stale entries in one go. - Retire the old "Scheduled Roon backups" folder. That's the one still hitting the retention/prune limit, your main
RoonBackupsfolder is pruning healthily ("found 9 backups… deleting 0 excessive"), but the old scheduled folder keeps trippingQuotaExceeded. Point the scheduled backup at a fresh, empty folder on the Ethernet share and let it start clean.
Most importantly, I’m taking the orphaned-lock-file finding to the team, because the investigation here is on making a wedged server recoverable without a hardware power cycle. Your logs give us a clean, specific reproduction to work from. If it recurs, keep noting the exact timestamp as you have been, that’s what let us pin this down.
Thanks again, Mark. 
Hello again, Benjamin! And, - yet again - thanks so much for your amazingly helpful and supportive research, work, suggestions and rely!
Snipping…
Presumably that truncation was itself actually due to the recycling of Titan?
I can see how that would cause it.
Possibly because I did have (by now a total! of) four addresses - two raw IPs and one unstable Wi-Fi one. Thanks again too to @DDPS for hel;ping ne out here.
Rationalized down now into just the canonical Ethernet by name, letting my Synology router do the resolving.
Would I be right in assuming that Roon’s failure to find the Mac’s address must have been (I hope is not still) some mistake on my part in reserving DHCP settings in the software?
Good. Thanks. No, I’ve had no problems. But neither have I had to do any restarting etc.
Thanks. Done.
…Retire the old “Scheduled Roon backups” folder…
Also done.
I see. I now have 2.70 build 1671.
But there’ll be more improvements/fixes soon, will there?
Good. Glad this may help resolving a wider issue for other users…
Will do!
And to you!
Hello @Mark_Sealey ,
Thanks again for your report. I wanted to touch base with some good news, our dev team has been able to dig into your report, and we believe we located the issue. We’ve put in a development ticket to address it, but as per policy, I am unable to comment on timelines. Thanks again for your report and for your pateince as this ticket makes its way through the developement queue!
Great. Many thanks @noris!
I really appreciate everything you’re all doing to help here.
Will it be obvious from the release notes when this fix (etc) is incorporated, please?
(Please do say if you need anything else from me.)
Hi @Mark_Sealey ,
Yes, we will incorporate it into the notes, but please note that the fix for this will not be a RoonServer release, but rather a RoonOS release. I see there is active dev work in progress, so thank you for your patience as this takes place. If anything else is needed, we will certainly reach out.
Great, @noris ; all understood. Thanks; and good luck!
Hi @Mark_Sealey,
The affected changes will target RoonOS 3.0, but aren’t included in the current Early Access testing release for 3.0 at this time. Otherwise, we’d invite you to test this already.
That said, this work is proceeding through the pipeline. We can share a note here when this fix is publicly available to users. Thank you!
Excellent. Thanks. I shall upgrade to RoonOS 3 as soon as I can, of course 
Good luck!
Thanks for your understanding, @Mark_Sealey !
Hi @Mark_Sealey,
Just pinging this thread to say hang in there a little longer. The most recent release today did not contain the relevant changes, but we hope to release them soon in an upcoming release. Thank you again for your patience.
