I think most (all?) QNAP users use Docker (and the Roon Extension Manager?) to run your extension. docker run has the -e option to set environment variables for the container and Docker Compose has its ways too.
If you mean environment variables for QTS then no, not over the GUI AFAIK.
Thank You for information where to find the Web Controller configuration file in the Qnap server. I understand that I need to copy it and change its name to “local.json” and edit it to enter the correct port for RWC. It looks like a fairly simple operation, but I’m still holding back because I want to be absolutely sure that I’ll do it right.
Thank you Robert for help
Mike, as I understand after reading the read me file, the layout for the screenreader is not ready yet. I think it will be better if I hold install the 2.0 version of RWCtil it come to beta stage.
I’m afraid that if it works unstable, I won’t be able to control Roon.
Thank you Mike for the hint. It is as I thought. I think I will only be useful when the screenreader friendly layout will be ready. I will gladly share my insights.
Thank you for the great program Robert
Yes and that’s also the way I installed the Roon Extension Manager and other Docker Containers on my NAS. This allows to make use of Docker options beyond what the limited QNAP GUI allows and it’s also easy to save a copy of the compose file’s content on the PC for later use (to have a backup/copy is always a good thing).
I think we just need a way to provide the port for users of the Roon Extension Manager. Yes it’s possible to add that option to its configuration but what about users that just install the REM to discover available extensions? If they later on decide to try out the RWC they might end up with a non-accessible extension. They might give up before they figure out that they have to add the option for RWC to the REM.
I had a command line option for port on the previous version, but I am not sure if it was used with REM. And honestly, I would rather to environment settings than command line options. The previous implementation used two additional packages - “command-line-args” and “command-line-usage” - that I was hoping to remove from this version.
That combined with the desire to use environmental settings for docker/kubernetes support means that the easiest solution is to just change the default listening port on the server. For dev, the backend listens on port 10000 so that I can use the Vue development tools on 8080. So it would actually simplify things to use port 10000, or another high port.
On the flip side, it would break existing user’s bookmarks or wrapper apps. For example, I use a QT Webengine front end for my day to day usage of RWC. Others use Electron based wrapper apps through various means. Sure, it is easy for me to change my wrapper app, but I am not exactly thrilled about the user experience of asking other folks to change their apps/bookmarks.
So I am on the fence about changing the listening port…
REM supports the installation of dockerized extensions. The Alarm Clock is an extension that installs as docker (if supported). The TZ option setable for it in REM just translates to a docker run -e command line switch AFAIK but Jan should now more/better than I.
Yes, by creating a Docker image for the Web Controller and including that in the Extension Repository it becomes possible to set the environment variable at install (container creation) time. Docker images are the default installation method if REM itself runs in a container, as is the case on a QNAP.
Here is a screenshot of the timezone variable where @BlackJack already referred to:
Hi, another question as I have some time today to tinker
My setup is RPI4 2GB, Diet-pi - Roon Bridge + web controller - Standard RPI screen. All of that packaged together using this case (which I think the only one to support RPI 4 and the 7 inch RPI touchscreen:
My second RPI 4 is using the standard RPI4 heatsinks. something like this one:
" Raspberry Pi Heatsink Aluminum Heatsink with 3M 8810 Thermal Tape"
At the moment I could not get any of them so had to set this up with no heatsinks. Straightaway I had to remove the back cover of the case because the screen was showing an over heating alert. Even with the cover off (so the RPI exposed), I feel the CPU boils (just touching it slightly). Questions:
With heatsinks (I should be able to order them now as they are in stock) - will I be able to close the case?
Can I get a visual CPU Temp somewhere so that I can monitor the CPU temp? I was already happy to get the overheat graphical warning.
This would require interaction with libsensors, which is out of scope for the Roon Web Controller project because it is hardware specific.
Additionally, because it is hardware specific, it would only be able to show the temperature of the system running the backend application. So if you are using a Raspberry Pi as a client in a web browser, the hardware temperature absolutely cannot be displayed.
I will hold off doing a PR on the repository update until the the 2.0.0 series is ready. I have an alpha image out on Docker Hub (pluggemi/roon-web-controller) which I will be keeping current with development.
The Dockerfile that I wrote to build the container is a 2 stage Dockerfile - one to webpack/compile the web application, the second to take that compiled web application and publish it. This is to keep the published container as small as possible - stage one has a LOT of dev dependencies that are not required at runtime.
I am not sure how well Docker manifest will handle a two stage Dockerfile, but I also have very little experience with Docker manifest since it is a relatively new feature. So if you have any pointers on that, it would be appreciated!