xthursdayx

Ah okay, I just assumed this was used to map volume access, I didn't realize it was specifically the download directory. Thanks!

I just set up this container for the first time in order to replace the Linuxserver ruTorrent container since it is no longer being updated, however I've run into an issue and can't seem to access the WebUI. I've attached my log here, however it never seems to get past the stage "Setting permissions recursively on volume mappings..." My settings are very basic as I'm not currently setting up any VPN and am only trying to access ruTorrent locally. You can see my settings below. Any ideas? supervisord.log

Did you transfer seeding torrents from one container to the other? If so, did you find a easy way to do this without manually downloading each .torrent file and rechecking them?

Glad to hear that the restore function is working for you as expected!

Sorry @steve1977, I haven't see any error logs like that and I'm not entirely sure what you mean by "download with the docker rather than updating the docker" or having "a lot of spinning balls". I'd like to help figure out what the problem is, but could you clarify what you mean exactly? Logs also always help. I assume you're using the default docker template from my repo (available via Community Apps)? If not, make sure to try that so we can try to eliminate variables while troubleshooting. Do you have a lot of ALAC/Apple Lossless files in your library? When searching to see what might be causing your error, the only thing that seems to through a similar error is ALACEncoder.cpp.

Yep, as @mikela suggestes, your problem stems from the fact that you have the /app and /data directories mounted in the same host directory. We previously identified this as the causes of some major problems associated with updating and I then updated my template. You should be able to fix this problem fairly easily by either: A) Choosing one of the options I describe here, if you want to try to keep your existing library. More work, but you get to keep your existing library data. or B) if you'd prefer to start from scratch (which will be easier, but will require you to delete your appdata folder and rebuild your library), you should change up your container configuration to match something like this (the backup and music directory location are up to you of course): You won't necessarily need to do to this manually - if you remove your RoonServer container and delete your RoonServer appdata folder, then search for Roon in Community Apps and my most recent template should be available, which has the correct directory mappings.

Post a picture of your container configuration in Unraid. I haven't run into that problem with any of the recent updates, and no one else has mentioned it recently, so hopefully it's a simple configuration problem.

Yes, you can update the Roon running in this container via the app. I think the fact that it is nagging you to update every time you start the app is just coincidental - Roon has released multiple builds over the last few days since 1.8 came out in order to fix issues that were identified after launch. Is it literally every time you restart you app, or is it just that you've had to update a few times over the last week?

I haven't had any problems restoring backup using this image Docker image/template combo, but that was restoring from the same setup (this Docker container running Roon Core on my UNRAID server). I'm not sure if there are any issues restoring backups across operating systems, but that might be a question for the Roon forums. However, if you find that it's an issue with permissions or anything associated with either my UNRAID DockerMan template, or Steef's original Docker image, I'll be happy to try to help sort it out. In either case, you'll need to include any error logs you have from the container when you try to restore your backup (if any exist, that is).

Yeah, a pic of your settings would help. If you're getting an error message indicating a duplicate mount directory it's likely that you're using the same mount point aka container path for the two different host directories.

@garethsnaim unfortunately, I'm not sure what's causing your issue and I suspect it is an issue unique to your set up and the actual Roon docker itself, rather than an issue caused by my unraid template (which follows steefdebruijn's mappings) . My suggestion is to post a new issue on steefdebruijn's github repo: https://github.com/steefdebruijn/docker-roonserver

I'm getting the following error in my Nextcloud log when trying to open documents via the Nextcloud mobile app on iOS: Fatal: Download without jwt Fatal: Download without jwt Anyone know what might be causing this problem?

Hi Austin, in-container updates seem to be working fine for everyone now after I updated the Unraid template. you can either start from scratch using the updated template in Community Apps, or follow the instructions I lay out in this post (see below) to preserve your existing container. It's a bit convoluted but should work. The final option is to backup your database using the internal back up option, scrap your docker container and then rebuild a new one using the updated template. Then you can try to restore the previous backup you made. However I can't promise this will work as I haven't tested this, and I'm not sure if the dividing up of directories that happens with the template will mess up the structure of your previous backup. Either way I'll be interested to hear what process you try out. Don't feel too bad if you end up losing your backup - I had to completely rebuild all the metadata for my lossless library (>50k tracks) when I was troubleshooting the update process when 1.7 (Build 667) was released and messed up... It happens to the best of us!

FYI: I just updated my Roon Core Docker container to 1.8 via the Roon app running on my MacBook with no problems at all. Everything looks great! Cheers!

As I mentioned in a previous post, we're currently completely overhauling Ferdi-server and combing the Docker image into the main Ferdi-server repo, while also updating much of the underlying infrastructure. As a result, the Ferdi-server docker container will likely function significantly differently in the future, so I an not able to troubleshoot any problems that are arising from the current configuration. I will however update this post as soon as we push the new Docker image and address any issues that may arise then. We'll aim to make sure that the password reset function is fixed during the process of updating the image.

I think most people, including myself, use external databases such as MariaDB, so it definitely works for most people. Have you tried changing your network type from `bridge` to `br0` or another custom docker net that MariaDB is also on? This is what the relevant part of my config looks like:

Hmmmm, I really have no idea... Unfortunately (fortunately?), I've never heard of this issue before (and the image has over 100k pulls), so it's kind of baffling. One thing is that I have ferdi-server running on a custom docker-network along with MariaDB and all of my other outward-facing containers, so they share the same LAN network IP range (172.19.0.0/24). I don't feel like not doing that should cause a problem, but something to check perhaps? One thing to note: we're currently completely overhauling the ferdi-server Docker image, so we will be pushing a new image onto Docker Hub in the next week or so which will handle almost everything differently. That doesn't really mean anything for your current issue, but it's just something to know for future planning.

It's hard for me to tell what the issue is based on the screenshot, but I'm wondering if you set up your database correctly? I am using almost the exact same settings as you with no problem. I see in your logs that you have an sql error that says `Access denied for user \`ferdi\`@\`172.17.0.8\`. This may be a stupid question, but did you create a ferdi database and user in MariaDB? It is necessary to manually create the database, user and password, if you want to use an external database.

I did the previous update through this Roon contianer and didn't have any issues (with the most recent settings I posted above), so I assume that this update to 1.8 should work as well.

Nope

THis may be a stupid question, but is there a way to use mkvextract through the GUI, or is it CLI only? Thanks!

@dkerlee It might be worth updating the instructions in the first post of this thread in order to avoid confusion, since it is no longer necessary to "Enable additional search results from DockerHub" since my template is available via CommunityApps.

As @realdielmentioned, everything should be working fine now, including updating. You can either start a new Roon container from scratch using my template (which is updated and working correctly), or you can migrate an existing Roon container using the instructions I posted here:

I'm in the same boat as @oldirtdog, I use Mylar to organize my comic and just use YACR to reader and server them. If you can describe any error messages you're getting I can try to update any permission issues within the image.

This does work with swag as is on my machine. There may be an issue with your port set up.