A minority request here: include a screen display geared to classical music. My mental model is to create a few (2-3) screen templates for different types of music. The two obvious ones are “Rock” and “Classical”. The primary difference between these screen templates is the amount and type of track data displayed. The Classical template, for example, would include the composer, and would extend the amount of space allocated to a track’s WORK and PART descriptions. Space for these additions would be borrowed from something, perhaps smaller album covers, smaller fonts, etc.
The user could access any template but is likely to just pick one and leave it alone. A really cool way to program templates is have the extension choose the best template based upon the track’s genre.
Not as minority a request as you would think. I listen to a LOT of classical as well and feel your pain.
However, I can only show what is in the API itself. And the API does not separate out WORK, SECTION, PART, COMPOSER, CONDUCTOR, ENSEMBLE or the many other useful tags for classical music. It shows lines of text only, the format of which cannot be changed. What the app shows is what the API presents.
That said, one things that really bugs me with the current version of the app is the length of the song lines. Scrolling through a long line like “Das Rheingold: Scene1. Der Welt Erbe gewänn’ ich zu eigen durch dich?” is downright painful. The new version does not do any scrolling and displays the entire line, which makes things much easier to read.
Here is an example screenshot of the Now Playing page in the new version - the first screenshot to be made public by the way!
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.