For the developer for RPMS, several tips-and-tricks are available to make development easier.

By default, the update-mechanism looks at the master branch on github. However, it is possible to override the master branch version, by setting the desired branch version to a different value.

In most cases this is the develop branch. Once set, you can update to the latest developer-features. But b/c this is considered as experimental (non-stable), use this option with precaution!

• ssh pi@rpms "sudo bash -c 'echo \"develop\" > /media/usbdata/rpms/config/update-branch.txt'"

Once the override-file update-branch.txt has been set, you can update your RPMS as usual, it will now update RPMS to the latest version on develop. See Update RPMS for details.

Simply delete the update-branch.txt file:

• ssh pi@rpms "sudo bash -c 'rm /media/usbdata/rpms/config/update-branch.txt'"

Note. Once an override is active, the current and available version do not play a role anymore.

Note. If local DNS does not work, the hostname rpms has to be replaced by the ip-address of that machine. See Check your network if local DNS works under Troubleshooting for details.

A regular install of rpms results in a Pi with hostname rpms, which is fine. As a developer, you want to test your code on a different machine then the one in production, on a second Pi; but having two machines within the network with the same hostname, results in errors.

You can opt for using rpmsdev as the hostname for that second Pi. This is done while burning the SD-card, as the first step in the installation process, see Installation

• While burning the SD-card:
  • Select a type: choose D for Development

The other steps in the installation process stay the same. In the end, this results in a Pi with a hostname rpmsdev, so you can easily distinguish and address the two, development (rpmsdev) and production (rpms). From now on, you can reach the development-server on rpmsdev.

Note. It must be clear that if you do not have a production/live machine for rpms in your network and you are using the installed Pi solely for testing purposes, there is no need to have a different hostname, the standard rpms will do just fine.

Tip. In case hostnames rpms and rpmsdev get mixed up, try to flush DNS:

• sudo systemd-resolve --flush-caches

As a developer, you want to test your changes on a physical machine (Pi). As the changes in the code are usually done on a different machine than the one on which the test takes place, you have to have a way to transfer your code to the (test) Pi and install them to see the result.

• clone/download the git-repo from github (instructions can be found there)
• place the code in a folder
  • example: ~/source/rpmusicserver
• switch to branch develop
  • cd ~/source/rpmusicserver # Example
  • git checkout develop

• cd ~/source/rpmusicserver # Example
• rsync -r ./* pi@rpmsdev:/tmp/rpmusicserver
  • password: rpms
• ssh pi@rpmsdev "sudo chmod +x /tmp/rpmusicserver/scripts/* && sudo /tmp/rpmusicserver/scripts/install-rp.sh"
  • password: rpms

Note. The transferred code is dependent on the chosen git-branch. By changing the branch, you can transfer and test any code in any branch.

Note. You can also do this 'trick' in a live, production-environment, but then you must know what you are doing, so don't try this at home! Usually, a production-machine is updated through the regular update-mechanism, in which code is retrieved from the git-repo on github (be it the master-branch or, if overridden, by another branch, usually develop).

Note. If local DNS does not work, the hostname rpmsdev must be replaced by the ip-address of that machine. See Check your network if local DNS works under Troubleshooting for details.

Testing on a (second) machine/Pi is the ultimate test, but to quickly see your changes in the web-interface (api or web) on your development-machine, we can set up an environment for exactly that.

In short, you have to open two terminals, each running a web-service, one running the api, the second running the web-UI.

• install local software (you only have to do this once):
  • sudo apt-get install python3-pip
  • pip3 install -r <source-folder of rpmusicserver>/web-interface/requirements.txt
• open terminal(s) and start web-services:
  • open a terminal
    • cd <source-folder of rpmusicserver>/web-interface/api
    • python3 controller.py
  • open a second terminal
    • cd <source-folder of rpmusicserver>/web-interface/web
    • python3 controller.py
• access:
  • web: http://localhost:1080
  • API: http://localhost:5000
  • cli: curl http://localhost:5000

Note. This environment is very limited b/c not all components which the code interacts with, such as disks or docker-containers or the Pi itself, are not available (however, you can spoof some of those components). But for seeing changes in the UI, this works just fine.

As a developer, it is useful to have at least one player which can connect to the LMS-server. We can easily transform a regular laptop or PC to a local player, just for testing purposes.

Steps for installing a local player:

• install squeezelite
  • sudo apt install squeezelite
• start player
  • squeezelite -o default -z -n "Local"
• stop player
  • sudo kill $(ps -ef | grep squeeze | grep -v grep | awk '{print $2}')

• curl rpms:5000/api/GetApiList
• http://rpms:5000/api/GetApiList

Top