EarlyAccess: RoonServer Docker Image feedback

[goat (J. V.)]

Correct this was at home on the wifi on original quality

[Otherford]

Hello y’all I’m so pleased to see Roon moving forward in development and listening to the community.

I’m currently on unRaid running steefdebruijn/docker-roonserver (dev and support thread here), and it’s all going swimmingly. Next time something goes oear shaped I’ll move over to the official docker. Maybe it will be out of early access then!

[gTunes]

@Stephen, @danny

Welcome to the party, @danny

I deployed the latest container. Here’s brief feedback:

• The rename of the data folder might be a bit challenging for some folks. I can confirm that stopping or downing the stack/container, renaming data → database, restarting or redploying works fine

• I’m running EA - specifying ROON_INSTALL_BRANCH instead of ROON_CHANNEL worked fine

• It looks like you’re no longer recommending specifying stop_grace_period (as an environment variable) or init (on the service). Just noting that here so that anyone updating will see.

• I’m using a compose file and I’m specifying “latest”. I use Dockhand as an Docker UX (highly recommended). Dockhad (or possibly Docker) doesn’t see your latest container as an update and that may be because you shifted the versions from 1.0.x to 0.0.x. So on a redploy, it won’t download the new container. Pruning the old image with the stack/container stopped or downed fixes this but that won’t be straightforward for some people. You may need to jump to 1.0.3 or later when you release and before people who don’t know how to prune move to the latest

• I noticed that you added TrueNAS Scale to the platform options. It’s actually now TrueNAS Community Edition, not Scale. As with the other NAS platforms, the path to app and music datasets is just a best guess. I wonder how helpful it is to make these best guesses. With TrueNAS the more helpful thing to do might be to create an entry in their app catalog - that’s the more standard approach these days. Maybe worth considering.

Hope this helps!

[s73nm (Sven M.)]

@gTunes

Dockhad (or possibly Docker) doesn’t see your latest container as an update

Dockhand showed me the updated without issue. Dockhand does not check continuously for updates. Perhaps the update was not yet available when the scheduled check ran?

@gTunes

The rename of the data folder might be a bit challenging for some folks. I can confirm that stopping or downing the stack/container, renaming data → database, restarting or redploying works fine

This was indeed required. I played dumb to seen what happend, but I Roon basically ignored the original data folder which resulted in a new server instance without any of my data.

I did notice an issue with my backups though, but I suspect this was due to a a change in case between my previous unofficial docker container having a roon folder and the official container having a Roon folder. After moving the backups to a new folder and mapping that folder to RoonBackups and then updating the backup schedule in Roon settings I was able to access my previous backups.

[gTunes]

@s73nm

Dockhand showed me the updated without issue. Dockhand does not check continuously for updates. Perhaps the update was not yet available when the scheduled check ran?

I know where the “Check for updates” button is on the Containers page

I’m not sure why it didn’t pick it up. They did build a new latest (v0.0.3) and Dockhand did see and pick that up. I did have an issue in the past like this with Dockhand related to how a container owner changed tags - I might be wrong about that being the case here. In any case, Dockhand’s image pruning is your friend when stuff like this happens.

@s73nm

I did notice an issue with my backups though, but I suspect this was due to a a change in case between my previous unofficial docker container having a roon folder and the official container having a Roon folder.

It shouldn’t matter what the host directories name is as long as you’re mapping to /Roon. Maybe they changed the casing of the mount point. I know they changed the casing of the default /Music folder. Mine’s mapped to “/music” and I didn’t bother to change that because you can, of course, add whatever is visible to the container in the Storage UI in the app.

[goat (J. V.)]

Question

I just did a docker compose pull & up -d
and I pulled and updated the docker image of Roon.

I did notice that after pulling and updating I had to restore my backup again to get all settings back.
Is this the normal way the updating of the docker will work in the future?

[s73nm (Sven M.)]

@goat

Is this the normal way the updating of the docker will work in the future?

I hope not, and it should not.

In this case, it was expected due to a change the was made in the container. Roon have renamed the data folder to database. When you check your Roon folder you will most likely see an “old” data folder and the new database folder. Renaming the data folder to database prior to performing the update of the container keeps all settings and history.

The change was noticed and briefly described here:

EarlyAccess: RoonServer Docker Image feedback

@Stephen_Shaw1, @danny Welcome to the party, @danny I deployed the latest container. Here’s brief feedback: The rename of the data folder might be a bit challenging for some folks. I can confirm that stopping or downing the stack/container, renaming data → database, restarting or redploying works fine I’m running EA - specifying ROON_INSTALL_BRANCH instead of ROON_CHANNEL worked fine It looks like you’re no longer recommending specifying stop_grace_period (as an environ…

[gTunes]

@s73nm

I hope not, and it should not.

Agreed.

@goat

Is this the normal way the updating of the docker will work in the future?

@goat - you should look at my full message because there’s a good chance that not only did you lose your database, but your “channel” specification is now being ignored because they changed the environment variable name. Since “production” is the default, if you were previously on EA, you will have switched to production.

Regarding the data folder, you have two choices:

1. Stop the container, delete the “database” folder that was created when you updated. Rename data → database. Start the container
2. Delete data

#1 gets you back to where you were before the update
#2 keeps you going forward from where you are now

@Stephen, @vova - it would be very helpful for you to be helping users through this. The people that trying this image need help getting through these and future changes.

Since you released a new EA today, it seems unlikely that you’ll go final but that’s just a guess. If the release is postponed, it would help to understand that. If QNAP users are still in a holding pattern while you work through the other alternative you’ve mentioned, that would help helpful to understand, too.

[Suedkiez (Just a fellow user like you)]

@Stephen @vova And if the production update that was announced for today is now being postponed (which I think would be a very good idea), please announce this, too. Production users are becoming confused and antsy.

[DDPS]

Yes, @Stephen @vova @danny —

Right now would be a very good time to announce a postponement. This should be a feature-driven deadline (as in, take the time to get it right) rather than a date-driven deadline. There is nothing urgently wrong with the software right now that dictates an immediate switch to anything.

In my mind, there should be multiple announcements about this shift as well - more emails, for sure, and whatever happened to the promised in-app announcement? We know that Roon has an in-app announcement capability, and it hasn’t yet been employed to make further announcements.

Is that because folks within Roon know that the deadline isn’t really today? Then say so.

Please take the time to get it right and to listen to the feedback you are getting from the community.

[MusicD]

Let’s not forget @Steve_Becker

[MusicD]

My thoughts here are Roon shouldn’t announce anything until it’s ready for release.

Lessons not learnt from Nug-gate it seems.

[Moonshiner (Thomas)]

Agreed, and there was also that announcement awhile back regarding ipv4 and ipv6 (I think) that caused a bit of stir and confusion - and eventually just fizzled away without any more info.

[Arindal]

Tried to get the container working via QNAP´s container station app, but after pulling and extracting the application, I get the following error message:

ln: failed to create symbolic link ‘/Roon/app/RoonServer/Appliance/libfreetype.so.6’: Operation not permitted

App is not running in the container, retrying to download and extract. Rest of the app data seems to be there, where it should be, around 200MB.

Is it possible that this problem is caused by the unusual filename ´libfreetype.so.6´? I am trying to run the container on an external volume, which is formatted as exFAT, so maybe the name is simply not working here?

[Suedkiez (Just a fellow user like you)]

@Arindal

libfreetype.so.6

This is a standard file name for a dynamically linked shared object library in Linux. It refers to version 6 of the freetype library, dynamically linked (so).

Normally symlinks are created so that an app can look for the generic „libfreetype“ file, which then symlinks to the specific implementation in version 6.

Looks like setting up the symlink failed for some reason. Not sure if exFAT has limitations for periods in file names, I doubt it. I’d use ext4 for a purpose like this.

@Arindal

ln: failed to create symbolic link ‘/Roon/app/RoonServer/Appliance/libfreetype.so.6’: Operation not permitted

Sorry about the libfreetype issue. This was a regression that slipped through. I’m working on fixing it right now.

I just posted v1.0.3 image which should have the libfreetype fix.

[goat (J. V.)]

ah oops I somehow missed this message. (or ignored it somehow lol)

I can see indeed that I now have the old data directory next to new database dir

[goat (J. V.)]

Thanks for this info.

one question: channel specification: I didn’t really set this ?

I just use docker compose yml file and only use the roonserver:latest to pull the latest docker image

roonserver:
    image: ghcr.io/roonlabs/roonserver:latest
    container_name: roonserver
    network_mode: host
    init: true
    restart: unless-stopped
    stop_grace_period: 45s
    environment:
      - TZ=Europe/Brussels
    volumes:
      - /share/CACHEDEV3_DATA/ContainerFast/RoonDocker:/Roon
      - /share/CACHEDEV1_DATA/Multimedia/Music:/music:ro
      - /share/CACHEDEV1_DATA/RoonBackup:/Roon/backup

I only was testing this docker as new solution: all other Roon apps are running the production version, and not early access.

And I also want to keep it that way: deploying EA stuff on my housholds phones is not appreciated

[s73nm (Sven M.)]

@goat

one question: channel specification: I didn’t really set this ?

@goat

all other Roon apps are running the production version, and not early access.

Then there is no need to set the channel specification. Roon will default to the production version. I’m doing the same.

@goat

- TZ=Europe/Brussels

Based on your timezone we could be neighbors