Right. Back to my infamous post, which is a little outdated:
See Which Synology NAS models support using M.2 SSDs to create storage pools? - Synology Bilgi Merkezi for the updated list.
2 Likes
I just āacquiredā a couple Synology 1513+ devices. This has been great for exploring the 7.1.1 issues.
4 Likes
Iām going to add an update to this, and I recommend that @vadim add to all relevant documentation, too.
When you restore a backup from a Roon on NAS library, everything looks all set in the Roon desktop application - history, tags, metadata, etc., are all there working as before.
BUT.
It appears that Roon needs to do fairly extensive background processing ā including
Background Audio Analysis ā after the migration. This will be manifest through Roon getting very slow to respond to things like track-to-track transitions, etc.
I donāt know if that is because that part of the underlying software cares about the fact that the internal path representation of each file changes during the migration (e.g., Roon on NAS pointed to
/var/packages/RoonServer/target/roonmnt/music/Non-Classical/Yes/Union/04 - Lift Me Up.flac and after migration to the Docker solution, the internal mapping for said song is /MyMusic/Non-Classical/Yes/Union/04 - Lift Me Up.flac). But it seems like a good possibility.
So, I recommend anyone noticing this slowdown be patient AND to turn on āScheduledā background audio analysis for 12+ hour chunks for a couple of days. After 2 nights of this for my ~64,000 track library, things settled down. When you notice things settling down, itās OK to reboot your Roon server and put the setting back to āUnscheduled.ā
2 Likes
Did you disable storage locations prior to creating the backup and importing into the container?
Yes indeed. Per my very own instructions too 
1 Like
For those who donāt mind going down an unofficial path, 007revadās github script for creating volumes on NVMe drives and for removing supported drive restrictions has worked well for me. Via this script I have an NVMe volume on my 1520+ and itās been rock solid. With my modest sized library and single endpoint use, performance is excellent
1 Like
After a successful migration last week from RoonOnNas. I left this package installed but stopped. I noted today Roon desktop showed that a Roon Server update available 2.65 -2.66 and asked to be installed. As far as Iām aware thereās no recent update to the docker version - 1.0.6 being the one I installed and run. Just asking for trouble and allowing the update and restarting, it attempted to start the RoonOnNas package. As far as Iām aware any updates to a docker version involve pulling the latest image and then rebuilding the container from the latest image. Roon desktop also is not showing the correct server container/image version.
No need to update or rebuild the Docker container. The Roon Server application updates itself within, just like it did in Roon on NAS. And yes, you are just asking for trouble if you start Roon on NAS up at this point.
2 Likes
Thanks. I thought the idea was that containers are immutable. Your reply suggests this is not the case for Roonserver. I run around 40 containers on my Synology and a far as Iām aware all the others are immutable Any reason for this being different apart from the obvious ease of keeping up to date
The Roon binaries are not part of the container. The container runs continually even through Roon updates. The Roon binaries are installed by the container into the mapped /Roon volume when the container is run.
2 Likes
The container doesnāt include Roon, which is downloaded and installed when building the container. This is a licence condition.
2 Likes
Thanks to both of you for the explanation.
1 Like