Docker images for Roon [Please Note: Using Dockers and VMs isn't supported by Roon]

[Steef_de_Bruijn]

Hi,

First, you use a roon core docker image that contains the roon core server software. This is violating the Roonlabs license. This is why I made my image some years ago (following this license discussion earlier in this thread).

On inspecting the dockerfile from the image you use, I see only two volumes exported (/var/roon and /music). How that translates to the screenshot you provided is beyond my knowledge of unraid, but I suspect you try to mount the volumes /app, /appdata, /Music and /mnt/user/isos/Roon Backup.

These volumes are not exported from the container so normally do not point to data used by or created by the docker container. If you can browse your local music from this installation it seems that /Music matches /music (which is normally not the case on *ix systems).

The problem with your growing image is that the data folder /var/roon is not host mounted thus fills the container disk.

Last but not least: In your screenshot you too seem to mount two different container folders (/app and /appdata) to one and the same host folder /mnt/user/appdata. Because this docker image does not use these folders this causes no problems, but as a golden rule: Don’t do this. The container thinks there are two separate folders where in fact there only is one. At least in my docker image this can and propably will cause problems (especially on roon core updates, although that is not yet confirmed in the github issue I mentioned some posts ago).

Steef

[Laurent_Gapin]

Dear Steef,

Thanks so much for looking at this.
It’s not my intention to violate the license, I’m certainly paying for Roon.
I’m not sure that I completely understand but it’s clear that it’ not configured properly.
What would you recommend that I should do? How should I export more volumes? Should I move /music to /Music? Should I create 2 different folders for /app and /appdata? I tried to follow what I saw posted but clearly I didn’t. The current configuration sees, scans and plays the music but it’s not entirely right as I continue to get songs that skip after a few seconds of play. Sometimes it’s fine, sometimes it’s not.
Thanks for your help,
Laurent

[Steef_de_Bruijn]

Hi,

The point of the license is that it is not allowed to re-distribute the Roon software that is obtained from the Roonlabs website. The image you downloaded does contain this software so that is in violation of the license.

You switched to my image now so the license issue at least is solved

The needed volume mappings now have changed too (my image does use different volumes than the previous one you used). You should map the four exported folders to separate host folders or you will regret at the next core update.

The /app folder is the folder the core software is downloaded to and it will be running from that location.
The /data folder is the location of the roon database the core is maintaining.
At least the /data folder should be on a (fast) SSD drive as per roonlabs recommendations. I don’t know if placing /app on a HDD will have a negative impact (I run /app and /data from two different SSD’s).

You can create two subfolders on your host under /mnt/user/appdata and point the /app and /data volumes to those two subfolders. You will lose your database however. To prevent this you could move all present data in /mnt/user/appdata to the new folder mapped to the /data volume so at least the database is retained (stop the container first of course). On next restart the software will be downloaded again but the database should still be there. It will also contain the software somewhere therein but cleaning that up will be your responsibility

So:

• stop roon core
• create subfolders under /mnt/user/appdata
• map the volumes /app and /data to these new subfolders
• move all present data that is roon related under /mnt/user/appdata to the new subfolder that is mapped to the /data volume
• restart roon core
• enjoy the music (hopefully)

Further notes:

• if local music is playing leave the /music mapping as it is now.
• check if the backups roon creates are showing up in your host folder /mnt/user/backup/roon; if it does also leave this mapping as it is now.
• If your /mnt/user/appdata is not on a (fast) SSD drive I suggest you seek another host folder that is located on a (fast) SSD drive.

Let me know how this goes.

Steef

[Xekomi]

@Steef_de_Bruijn

If your /mnt/user/appdata is not on a (fast) SSD drive I suggest you seek another host folder that is located on a (fast) SSD drive.

Very much this. If you want to run Roon and don’t have a (fast) SSD cache drive, stop reading right now and go get one.

Another note:

use /mnt/cache/ rather than /mnt/user/ (so /mnt/cache/appdata rather than /mnt/user/appdata/) for stuff that should be on your cache disk. Obviously, this normally shouldn’t apply to your music share.

This eliminates a cause of problems (think UnRaid or a docker suddenly dumping stuff that really shouldn’t go there, like Roon’s database, on the array).

[Laurent_Gapin]

Thanks to both of you.
I think I do not understand the structure of what you both are talking about but I will try nonetheless and report.
I do have a cache drive (120 Gb). Does it matter that whatever is written on the drive is then written on the array every night? I’m clearly lost

[Laurent_Gapin]

excuse my ignorance but how/where can I create the appdata on the cache drive?
/mnt is actually empty
Is my array completely not set up correctly?

[Steef_de_Bruijn]

Hi,

This is a bit too specific unraid for me to help you with but at least take note of roonlab article at https://help.roonlabs.com/portal/en/kb/articles/roon-server-on-nas

Take note of memory size (at least 4gb) and ssd (at least 64gb) so I don’t know what the SSD in your unraid is used for but half of it will be taken by Roon given their writing.

The actual size taken is depending on the number of songs, albums etc in your library. My library of a 1000 albums (Some local, some streaming) takes only 5Gb of ssd space so YMMV).

Steef

[Xekomi]

@Laurent_Gapin

I do have a cache drive (120 Gb). Does it matter that whatever is written on the drive is then written on the array every night?

In the context of Roon: not really. In the context of UnRaid, it’s better, but that’s a bit of an unRaid question

@Laurent_Gapin

I’m clearly lost

Nah, you’re not. It’s a bit confusing, and I made things worse. Sorry about that.

@Laurent_Gapin

excuse my ignorance but how/where can I create the appdata on the cache drive?

It should already be that way (that’s the way it is by default, and it’s also why appdata is in orange in the screenshot you posted earlier), but you want to make sure your appdata is assigned to “cache only”, in shares - like so:

Now, this is usually enough. But bugs being bugs, there are cases where things don’t work out the way they should, so although this isn’t necessarily best practice, I personally prefer to point my dockers straight to the cache drive, like so:

Normally, the folder should already have been created on your cache drive (because /mnt/cache/appdata should just be /mnt/user/appdata by another name)

Note that my music share also points to a single drive (that’s why it says /mnt/disk9/Music and not /mnt/user/Music/). The reason I did that is that is that as long as my collection is big enough to fit on a single disk, doing things this way allows me to spin up only one drive, rather than the whole array (or having the other drives spin up and down), when I’m listening to music.

@Laurent_Gapin

/mnt is actually empty

Nope, you’re probably just looking in the wrong place - that looks like /mnt/user/ to me.

What might be going on is that your Krusader docker might not have access to the root folder. If that is the case, changing this should be fine, but please check with the (much, much) more knowledgeable folks than I am over on LimeTech’s forums to make absolutely certain you wouldn’t be doing anything dangerous or stupid by allowing that to happen.

I’m not entirely certain what your docker image is doing there, though, and that’s something you probably really want on your cache drive.

From the screenshot you posted, /mnt/user/system is on the array, and not just on cache, so your docker image is on the array, and that might slow things down unnecessarily.

Here again, please double check with the folks on the UnRaid forums.

@Laurent_Gapin

Is my array completely not set up correctly?

Looks pretty OK to me. Couple of things to check on to make sure all the bolts are tightened is all.

[Laurent_Gapin]

Thanks Xekomi !!! Very useful and informative. I like the idea of all the music on one drive so only thi sone would spin. I think I might be too later for that and my library is way too big.
The appdata is cache only in the share, so that’s good.

From the screenshot you posted, /mnt/user/system is on the array, and not just on cache, so your docker image is on the array, and that might slow things down unnecessarily.

What path should I then set to get it on the cache only?

Getting there

[Xekomi]

@Laurent_Gapin

What path should I then set to get it on the cache only?

/mnt/cache/[foo] , so in this case, /mnt/cache/system.

Please look around on the unraid forums to figure out how to do that properly, i.e, without breaking stuff. I’d be surprised if that was the cause of the problems you’re describing, but it’s possibly worth doing.

One more thing: looking at the screenshots you posted, there’s something else you might want to try…

In your container paths, please make sure everything is capitalised properly (/mnt/user/Backup/roon is currently input as /mnt/user/backup/roon, for example) - i’m wondering if the docker isn’t trying to write to something it doesn’t have access to (because it doesn’t exist) on the array, and this writing into itself.

The easy, relatively foolproof way to do this is to click on the line you want to edit, and use the pull-down navigation menu.

You might also want to make a Roon subdirectory inside your appdata folder, to keep things nice and tidy, i.e, /mnt/user/appdata/Roon/app and /mnt/user/appdata/Roon/data or something of the sort. If you choose to do this, please note that you’ll potentially loose your library, so please do this in four steps: first fix your backup location problem in the docker, then do a backup of the library, from within Roon, to the now a-ok location, fix the /app and /data paths, and, from within Roon here again, re-import the library from the backup location.

[PeterD]

@Yethal

No idea how the container could’ve grown to 100GB unless it is somehow pulling all your music into the container

You cannot grow the container, it is unchangeble after you built it.
The above is true for every docker container.

[Yethal]

Image is unchangeable, container isn’t.

[PeterD]

Yeah your right… mixup of terms … sorry

[Steef_de_Bruijn]

Incorrect volume mapping most probably caused the room database to be written onto the container disk instead of the host disk.

Not a good idea because containers can be recreated on image update and the data on the container disk would be lost.

[Robert_Blakely]

@Laurent_Gapin

You guys seem to have Roon running on Unraid

Not me. I tried and tried and gave up. Big disappointment. I could not stand the update nags. Nag, nag, nag. Now I run Roon core on a Win10 PC, and it looks to the Unraid NAS for the music files. The NAS is always on, and the PC I shutdown every night. When I start Roon on the PC, it becomes useable after about 4 minutes. I am hoping that eventually Roon supports Unraid. It is a pity that I need to run 2 computers to listen to music.

[Laurent_Gapin]

I hope I now have everything in order.
Rebuilt the library with new location
It plays… but it continues to skip songs. Sometimes 15 sec, sometimes in the middle, sometimes it’s fine
This is driving me nuts and I’m almost to the point that either I switch to Volumino or I mount the smb share to my mac and run the Roon core from that mac to the other mac mini with the stereo connected to.

[PeterL]

I’m using the same container without any issues. What is your server? CPU? RAM?

[Laurent_Gapin]

Intel Xeon CPU E3-1270 v3 @ 3.5 GHz with 16 Gb RAM
it used to work fine (before update) but it’s now unusable. Couldn’t pass 15-30 seconds on each song tonight
I assume one process is messing it up but I cannot figure out what it is.
Thanks in advance for any help/suggestion

[Xekomi]

@Robert_Blakely

I could not stand the update nags. Nag, nag, nag.

What update nags are you talking about ? I’ve had mine running for 11 months or something, and the uptime says “3 weeks”, which I’d guess is probably when I updated to Build 667.

@Laurent_Gapin

it used to work fine (before update) but it’s now unusable. Couldn’t pass 15-30 seconds on each song tonight

One thing I’d try is to spin the array up (so on the main page), and see if the skipping issue is still there.

Another is to try with another docker - fwiw, I’ve been using the ronch image, and it works fine - the idea here being that maybe there’s some library weirdness or whatever that might be fixed by a clean slate, and it might be a more efficient use of time to give a completely different image a go (complete with a different folder allocation obviously).

I don’t recall you saying how big your library is, but your ressource usage does seem pretty high compared to mine (I’m at 1.7 gigs of RAM for 7’000 albums / 100’000 tracks), so although it really shouldn’t be a problem on paper, I can’t help but wonder if the limits to what a docker under UnRaid can handle might be lower than a full-on ROCK install on the same hardware, and if you aren’t pushing the limits of how many tracks a docker can handle… if you’re at say half a million tracks or something, maybe a VM would be better suited.

[Laurent_Gapin]

Yes I’m talking about the 667 update.
I agree with you that the resource usage seems high. This is the only docker running on Unraid. But I don’t know how to judge, 17596 albums and 111461 tracks. I’m trying to clean up