xthursdayx

I haven't dealt with this either, so unfortunately I can't speak to it. Seems that your server has more than enough resources to run Roon quickly, so I wonder if this is a local networking issue?

For what it's worth, I just updated the Roon CORE running in this docker container to 1.7 (build 710) via the Roon Remote App running on my Mac without any problems. I've updated my template accordingly, so anyone interested in starting over with the correct mappings can delete their Roon container, delete your appdata directory, and pull the container again using the new template. If you backed up your library via Roon you should be able to restore the backup once you have your new CORE up and running. If you'd prefer to just update your existing container to the correct mappings, see my instructions above. CC @dkerlee Edit: you may need to wait a bit for my template to update in Community Apps.

This is a good suggestion - as long as the docker container's /comics directory is mapped to the location of your comics on your UNRAID host then the command: docker exec yacserver YACReaderLibraryServer create-library <library-name> /comics, should work (with <library-name> changed to whatever you want to name your library, e.g. docker exec yacserver YACReaderLibraryServer create-library Comics /comics. @Salted11, when you say that you "see the yacreaderlibrary folder created in [your] share", do you mean the yacreaderlibrary appdata folder? Because that isn't actually where the library information is stored. The library is stored in a dot directory in at /comics.

You can ignore that error (unless you have comics in 7zip format). The error has to do with the 7zip backend YACReader used to use being broken. Your library should have been created just fine despite the error. Have you tried checking the YACReaderLibraryServer WebUI to see if it shows your library?

Thanks @d2dyno ! Just to clarify, was there a reason you added these lines to /boot/config/go rather than your .zshrc?

I'm not sure why, since it seems like you're no longer having this problem @ksignorini, but I'm not having this exact issue with neofetch. I'm on 6.8.3 and Nerdpack is up to date. Any ideas @dmacias?

Late post, but hopefully one of you all might see this. I was just wondering how you're handling making your .zshrc and any plugins persistent? Thanks!

Unfortunately not, but I haven't worked on this at all lately. However, I will say that things seemed to work alright, despite the error message.

This docker container is designed to check for and (if necessary) download the most up-to-date version of YACReader at run time. If your container is not updating, you can try to delete the current container and pull the container again to see if that will properly update YACReader. I will note that I'm using the same container and haven't had any problem syncing reading progress...

Sorry, I don't have that much experience with youtube-dl and only use it for a couple of channels I download, so can't speak to this too much. But I do know that youtube-dl has downloaded over 60 videos from one channel that I added via gPodder. So long as your config data is set to your appdata share, as my template suggests, then your settings should be maintained when the container is restarted.

Sorry, actually youtube-dl support is working fine, I just forgot to update the image on Docker Hub. Please try deleting your container and pulling it again. It should work after that.

HI @realdiel, sorry to just get back to you, work has been crazy. Thanks for your help troubleshooting this! I'll try to explain the process as clearly as possible. What I suggest you do is this: First back up your roonserver appdata folder (copy the folder manually) and then also backup your library internally through the Roon interface. Then stop your roonserver container. Access your server via ssh/console and create an /app and /data directory inside of the your roonserver appdata directory (/mnt/cache/appdata/roonserver/). Make sure that these directories have the same owner:group as the rest of your roonserver appdata directory: probably nobody:users. Move the following files and subdirectories from /mnt/cache/appdata/roonserver/RoonServer to /mnt/cache/appdata/roonserver/app/RoonServer/: /Appliance, /RoonMono, /Server, Version, check.sh, and start.sh. Move the following files and subdirectories from /mnt/cache/appdata/roonserver/RoonServer to /mnt/cache/appdata/roonserver/data/RoonServer/: /Cache, /Database, /Logs, /Settings, and /Temp. Move the following files and subdirectories from /mnt/cache/appdata/roonserver/ to /mnt/cache/appdata/roonserver/data/: /RAATServer, /RoonGoer, and .rmembid. Now, edit your roonserver container settings through the Unraid interface and change the /data and /app folder mappings to: /mnt/cache/appdata/roonserver/data/ and /mnt/cache/appdata/roonserver/app, respectively. Now restart your container and check to make sure it is working correctly and recognizing the files at the newly mapped locations. Finally, if everything is working please try to update Roon using the internal updater in the Roon interface. If this works, great! Please report back. If it doesn't work please also report back with the container logs and a description of what went wrong.

I can answer this one: I created my docker template to use 49152:65535 in order to match the ports used in the example turnserver.conf from the Coturn dev. Instrumentisto chose to use fewer ports in their suggested set up for their Coturn docker container, but it shouldn't cause any issues either way. The broader range gives Coturn more ports to utilize, but also requires you to allow connections on more ports. It's really up to you how many ports you allow, based on your firewall/router set up.

Yeah, it looks like implementing logs would require changing the way the base server is implemented, which is beyond the scope of my involvement with the project. Sorry about that. I will raise the issue of logging with the rest of the dev team though.

Good question! I'm not actually sure about that, since it would be the actual Ferdi Server that would produce this log rather than the docker image (which is what I primarily focus on). I suggest that you open an issue on the Ferdi Server github page to ask about this. Once we figure out if and how logging happens I can integrate it into the docker container.

I have made a new thread related specifically to the updating issue here: Hopefully someone more familiar with how Unraid handles Docker permissions will comment. Cheers!

This issue is related to a problem I and others are having regarding updating steefdebruijn's Roon Server Docker image using Roon's internal updater. This issue is discussed in this thread on the UNRAID forums and in this issue in steefdebruijn's repo. The reason I wanted to post here is because in the discussion about the issue listed above steefdebruijn told me that this problem with updating only happens for users running the container on UNRAID; apparently it works fine on other NAS devices (synology, etc) and on other Linux distro's running Docker. This leads me to believe that there is something about how UNRAID's DockerMan system deals with permissions that is causing the problem, however I don't even really know where to begin looking to fix this issue. Most of the people running Roon Server on UNRAID are using my docker template, which can be seen here: https://github.com/xthursdayx/docker-templates/blob/master/roonserver.xml There are two required mounted volumes: `/mnt/cache/appdata/roonserver/:/app` amd `/mnt/cache/appdata/roonserver/:/data` and two important but not required volumes: `/mnt/user/Media/Music_library/:/music` and `/mnt/user/Backup/Roon_Backup/:/backup` After updating Roon Server using the internal updater, the container's docker log reads: ``` /app/RoonServer/start.sh: line 50: /app/RoonServer/Server/RoonServer: Permission denied /app/RoonServer/start.sh: line 34: kill: (11) - No such process ``` which is what leads to believe that the permissions are changing upon update. Please see a detailed description of the update process and subsequent container failure with logs and screen shots here: https://github.com/steefdebruijn/docker-roonserver/issues/8#issuecomment-714838274 Does anyone have a sense of what might be going wrong, or how to best go about troubleshooting this?

Based on the error message I saw "/app/RoonServer/start.sh: line 50: /app/RoonServer/Server/RoonServer: Permission denied". I think that the issue has to do with the permissions of the Roon start script changing after the update, rather than a port issue, but I'm not positive.

That was a good question, actually. I just realized that I hadn't had to update the CORE (running in Docker) until right now. I just backed up my library and then updated to Roon Version 7.1 (build 610) using the internal updater and ran into exactly the same problem that it seems like you guys are having. Once Roon Remote on my Mac and Roon Core (on my server) rebooted I was forced to sign again and connect to my Roon Core as if this was the first time I'd done so. I tried to restore my library only to find that after the restore was complete my Roon Core had disappeared and now I've had to reinstall the container. I suspect that this may be an issue related to running Roon inside a docker container so I've created an issue in steefdebruijn's repo: https://github.com/steefdebruijn/docker-roonserver/issues/8 I encourage you all to post your experiences in this issue. Particularly if you have and logs - I accidentally deleted mine before I could add it to this issue.

That's been the perk of working from home for me - actually getting to use Roon and enjoy my music collection. I guess I've been lucky, I haven't had any problems with Roon running in a docker container so far, so can't really speak to any of the issues. Sorry to hear that you all are having so many problems!

Cheers! Hope it works out for you! Let me know if you run into any issues.

Sorry, I won't be providing support for the Starbix Synclouge container any longer since Linuxserver released an updated docker image here: https://github.com/linuxserver/docker-synclounge It is also available in the Community Apps plugin.

The YACReaderLibrary.ini file is in a directory inside of the running YACReaderLibraryServer container - `/root/.local/share/YACReader/YACReaderLibrary/`. It is not mounted to any directory on your host server. So, you wouldn't be able to access it without entering the docker container via `docker exec -it <container name> /bin/sh` from command line. However, that won't help you, since the way that this docker container is configured is based on exposing port 8080. You can, of course, change the external port that YACReaderLibraryServer is accessed on by updating your docker template, but internally that port will still be mapped to 8080. If you change the YACReaderLibraryServer port in the YACReaderLibrary.ini file you will need a new Dockerfile that exposes your new port instead of 8080, thus you'd need a different docker image designed to expose that port. If you're inclined to trouble shoot this issue, you could fork my docker image repo and then change the listed port in the bundled YACReaderLibrary.ini file, change the dockerfile to expose your preferred port, and push your image to Docker Hub so you can try it out on your own machine by subbing your repo for mine in the docker template on Unraid.

This may not be the right place to ask this, but I was wondering if anyone could help figure out me to write a script to automatically sort files that NZBGet downloads via RSS Feeds. I have NZBGet set up to download certain publications in PDF format as they become available, along with other files (e.g. *.nzb). NZBGet places the files in sub-directories named after the file within the ~/Incoming directory, e.g. ~/Incoming/The.Globe-October.2020/The.Globe-October.2020.pdf What I want to do is create a script that will monitor the ~/Incoming directory and all subdirectories for new PDFs and then move only these new PDFs to specific directories, based on their file names. For example, all PDFs whose names begin with The.Globe should be moved to the directory ~/Publications/The_Globe, while all PDFs that begin with Fish.Times... should be moved to the directory ~/Publications/Fish_Times/. I would then like to remove any leftover files (e.g. *.nzb) and the remaining directories in ~Incoming. I believe that I can either use inotifywait to monitory the ~/Incoming directory or just run the script periodically via the UserScripts plugin. To sort the PDFs I think I will need to use shell's case statement, but I'm not sure exactly how to write the script correct. This is what I have so far (it's probably incorrect, just a start...): #!/bin/bash INPUT=~/Incoming OUTPUT=~/Publications CD $INPUT find . -type f | while IFS= read filename; do case "${filename,,*}" in *.nzb) : ;; # Exclude *.nzb files from being moved The.Globe*) mv "$filename" "$OUTPUT/The_Globe/" ;; Fish.Times*) mv "$filename" "$OUTPUT/Fish_Times/" ;; esac rm -R $INPUT/* # Remove remainging files and sub-directories done Any suggestions for how to best/correctly sort the PDFs, monitor the directory (whether with inotify wait or just by periodically running the sort script via UserScripts), and remove the remaining directories and left over files? Thanks!

Just following up to see if anyone knows how I might make Nextcloud play well with characters like these: ö, í, å, etc