Roon Extension Manager v1.0 beta3

Ok, added this to the Dockerfile and now it works! Thanks for the tip!

Good to hear that it is working now.

To explain; in the first case you run the command directly on the Pi, but in the second case it is executed in a container where it cannot access the Python installation of the host. The modified RUN command installs Python in the container before executing the npm install command.

1 Like

Now it builds, but i get this error:

Generating repository.json
Error: No such container:path: roon-extension-manager:/home/node/.rem/repos

At this point the image is created and the build script tries to include it in the local repository of the Extension Manager installation, but the manager hasn’t been installed yet.

Please use the setup script to install the Extension Manager on the Pi, see description in the first post. After that you make the modification to the repository.json file I described earlier. Then that file should be copied into the container:

docker cp <path/to/>repository.json roon-extension-manager:/home/node/.rem/repos

If that succeeds you should be able to install your extension from the Test category of the manager.

Thank you so much Jan for your patience!

The extension manager (1.0.0-beta2) was already installed and running. I modified the repository.json file and used the docker cp command.
Then i run build.sh again and get this:

Generating repository.json
Error response from daemon: extraction point is not a directory

Also i don’t see a test category in the extension manager settings.

Ah, I think the directory doesn’t exist yet, it can be created with:

docker exec roon-extension-manager mkdir .rem/repos

Running the script again will revert the changes you made :frowning:. After manually copying the file into the container there is no need to run the build script again.

A restart of the Extension Manager is needed before the new entry will show up.

I will fix these issues in the next version of the build script.

The build script does
“docker cp out/$NAME/.reg/etc/repository.json roon-extension-manager:/home/node/.rem/repos/$NAME.json”
, i.e. it copies and tries to rename the json file. But It seems that only a directory is allowed as the target of the docker cp command. So this is why it fails.

I renamed the json file locally and copied it using
“docker cp $NAME.json roon-extension-manager:/home/node/.rem/repos”
which worked.

Unfortunately, i still don’t see the Test category and cannot start from the extension manager. The local docker file using the generated script runs though.

It would be good to have a look in the container to see what enden up there. Get in with:

docker exec -it roon-extension-manager sh

Then you list the repos directory to see what is in:

ls -l .rem/repos

End check the content:

cat .rem/repos/roon-spacenav.json

And get out with:

exit

Does this all look OK?

Argh, yes, repos was file, not a directory. Deleted the file, created a directory and copied the repository.json file to the container. Now it works - i see the Test category and the extension.
Thanks Jan!

Now i have the problem that it cannot find the USB device. I entered /dev/bus/usb/ as device path when installing, but it does not work. Works for roon-extension-powermate though.

We are getting closer and closer :slight_smile:

I think you also have to supply the bus and device ID in the path. If you enter the lsusb command you should look for the two numbers for your space mouse and append them to the path, e.g. if bus is 001 and device is 004 then the path becomes:

/dev/bus/usb/001/004

No, this does not work. I probably have to look into libusb vs rawhid as in roon-extension-powermate. I can get powermate running only with libusb and /dev/bus/usb/.
I also think it is too difficult for the end-user to cope with device names. Is there no better way when using docker files?

Can we run the docker container in “–privileged” mode to circumvent all these USB device problems and make it easy for the end-user to install such extensions?

I still can’t get the USB running inside the container. I tried:

  • set device name during installation to /dev/bus/usb/001/003 (which is where the device is connected)
  • HID.setDriverType(‘libusb’); in code and device name /dev/bus/usb during installation (which works with powermate for some reason)
  • creating a file /etc/udev/rules.d/95-spacenav.rules with content “SUBSYSTEM==“usb”, ATTRS{idVendor}==“046D”, ATTRS{idProduct}==“C626”, SYMLINK+=“spacenav”, MODE=“660”, GROUP=“dietpi””

I wonder if this can be a permission issue. The powermate extension uses the root account in the container while the generated Dockerfile uses a normal account. You can check if this makes a difference by removing the USER node line from the Dockerfile and running build.sh again.

Yes, that was the problem!
I have HID set to libusb and i use ‘/dev/bus/usb/’ as device path during installation.

Thank you so much for your help! I still wonder if there is better way to pass USB devices to docker without having the user to specify a device path.
Thanks for all your help and patience Jan !

1 Like

That the bus and device IDs don’t have to be specified means that the path is very generic and can be set as the default value. A default value can be specified before the colon in the devices entry:

    "options": {
        "devices": [
            "/dev/bus/usb/:USB Device Path"
        ]
    }

I will add this default value for SpaceNav and Powermate when I handle the merge of your pull request.

You’re welcome. Thanks for being the first user of the Extension Generator tool!

Two updates resulting from the activities of the last few days:

  • Extension Repository version 1.0.4 includes the SpaceNavigator remote control
  • Extension Generator version 1.0.1 improves the integration of the generated extension in the locally installed Extension Manager
2 Likes

Great work, Jan! This is a great service to the community.

Extension Manager 1.0 is now also available for the arm64 architecture, so if you are running the 64 bit version of e.g. DietPi on your Pi3 or Pi4 then you can install now!

With the Docker approach for extensions an image has to be created for each processor architecture, this means that the selection of extensions is limited at the moment. I will take care that at least all my extensions become available for arm64.

In this first round the Entrypoints extensions are included, as I had a request for this in the past. I will post updates in this thread when others become available.

I had to reflash Dietpi as a previous upgrade failed.
Just installed Dietpi v7, installed Docker for Linux and ran the install script.

image

Extension manager is running.

image

But only System and Entrypoints can be selected.
Are the other extensions not yet available on Extension Manager 1.0?
I can’t find Extension Snapshots either.

Only 64 bit arm installations have this limitation, I tried to make that clear in my previous post. The Snapshots and Alarm Clock are on my list to add next. Any specific extension you want to use?