Transform a Raspberry Pi into a streaming/-file-server for your music with LMS (Lyrion/Logitech Media Server/Squeezebox), Samba, Transmission, Syncthing, transcoder, etc. in a few simple steps.
System requirements
Check your network if local DNS works
Installation of RPMS on a Pi
Troubleshooting
Folder mapping
Update RPMS
Transcoder
Backup
Disaster Recovery
Development
Migrating to 1.0
To detect if your network supports local DNS, execute the following command in a terminal:
nslookup $(hostname) $(ip route | grep default | awk '{print $3}') | grep "Can't find"Check for output:
Installing RPMS on your Pi can be done with a few simple steps, described below. But first, you should test your network if local DNS works.
sudo apt-get install nmapwget https://github.com/markbaaijens/rpmusicserver/archive/refs/heads/master.zip -O /tmp/rpmusicserver.zip && unzip -d /tmp -o /tmp/rpmusicserver.zipsudo /tmp/rpmusicserver-master/scripts/burn-image.shsudo /tmp/rpmusicserver-master/scripts/format-usbdisk.shwatch nmap rpmsrsync -r /tmp/rpmusicserver-master/* pi@rpms:/tmp/rpmusicserver
ssh pi@rpms "sudo chmod +x /tmp/rpmusicserver/scripts/* && sudo /tmp/rpmusicserver/scripts/install-rp.sh"
pi is changed to rpmswatch nmap rpmssmb://rpmscurl rpms:5000ssh pi@rpmssmb://rpms/<music folder>For several services within RPMS, the container-technology docker is used. Within docker, there is no direct link to the file-system, but this is achieved through a virtual folder which is set during installation.
Normally, an end-user does not have to know about these virtual folders, but there are a few exceptions primarily around LMS and SyncThing, these specific cases are documented here. So when working on the inside of the docker-infrastructure, either LMS or SyncThing, refer to the virtual folders.
/music/media/usbdata/user/musicsmb://rpms/[music]/user/media/usbdata/userNote. SyncThing maps to /media/usbdata/user, which is the root of all Samba-shares, public, music and downloads. Thus, you can sync any folder on any share with SyncThing.
If you want to sync your music-files, with Synthing:
/media/usbdata/user/music smb://rpms/[music]/user/musicSome common problems in their solutions.
Sometimes the pi is not visible in the network, either by hostname rpms or even by ip-address.
ping rpmsnmap $(echo "$(hostname -I | cut -d"." -f1-3).1")/24 -p 22 --openIf everything fails (no hostname shown for pi, multiple ip-addresses for hostname, not able to ping on hostname, etc.), try:
On some local networks, there might be a problem present that the hostname of all connected devices, including RPMS cannot be resolved. In practice, ping rpms does not return anything. So any command directly targeted at RPMS such as ssh pi@rpms does not work. This is a problem within the router/network, the origin of this problem is unknown to date.
The good news however is that a device is always accessible by ip-address. So once you know the ip-address of your RPMS-instance, you can install, configure and use RPMS. All you have to do is the following: in any command in the section Installation of RPMS on a Pi (and following sections), replace RPMS with the discovered ip-address.
So for example, if the ip-address of RPMS is 192.68.1.20: ping rpms will become ping 192.68.1.20. And ssh pi@rpms will become ssh pi@192.68.1.20. In your browser, LMS rpms:9002 will become 192.68.1.20:9002 Etc.
Note that the ip-address might change over time b/c RPMS does not use a fixed address, but instead depends on the router which determines the address. In that case, point to the new address.
When migrating from an existing LMS-server or upgrading your Pi-hardware, you have to reconfigure all players to point to the new LMS-server (even if LMS has the same name). This is especially true for Squeezebox-hardware like Squeezebox Classic, Duet, Touch, Radio, Boom or Transporter. Note: clients with piCorePlayer will autodetect the new LMS-server.
Reconfiguring is best done:
Update your RPMS-server by the web-interface:
You can also opt to update through ssh on rpms:
ssh pi@rpmssudo update-rpmsNote. Update is disabled when there is no newer version found.
Note. For developer-purposes, you might want to update from the development-branch, to have the latest-and-greatest version of RPMS. Beware that this might be unstable, so use with caution! See Update from another git branch for details.
Within RPMS, there is a transcoder built in, for transcoding your lossless music files (flac) into lossy ones (ogg or mp3). By default, the transcoder is not active, it must be configured to become active.
For getting transcoding to work, take the following steps:
flac under smb://rpms/musicflac/music/music/flacSource Folder
flacogg under smb://rpms/musicOgg Folderoggmp3 under smb://rpms/musicMp3 Foldermp3From now on, file transcoding will take place and lossy-files will automagically appear in the given lossy-folder without any interaction.
In the Transcoder-page, You can also click on the Transcode-button, to start an immediate transcoding session, for if you do want to wait for the automatic session to kick in. Note that this button is disabled if transcoding is not configured.
Ogg Folder and Mp3 FolderYou can make a backup of all the data contained in your RPMS-server. You have the choice for a full, server-based backup. Or a remote backup, where your backup contains basically the data/user-part of RPMS. A proper backup is the basis for disaster recovery.
The advantage of the server-based (local) backup is that the resulting backup is an identical copy of the data-disk, making it very easy to switch in case of a disaster. The disadvantage is that you have to have local access to the server (Pi) for attaching the backup-disk.
This backup will be done to a dedicated backup-disk, connected to the Pi itself, thus a server-based backup.
wget https://github.com/markbaaijens/rpmusicserver/raw/master/scripts/format-usbdisk.sh -O /tmp/format-usbdisk.sh && chmod +x /tmp/format-usbdisk.sh && sudo /tmp/format-usbdisk.shIn case of a server-based backup, your backup will be made to a separate backup-disk. You can view the data on this disk, either online or offline:
smb://rpms/backup and then you can view all the files on that disk.The advantage of the remote backup is that you can use a protocol at wish, be it ssh/rsync or syncthing (which is built-in in RPMS) or SMB. The disadvantage of a remote backup is that in case of a disaster, it is a lot more work to get up-and-running again.
Note that system-data is also present on the data-part ('Public') in the form of a file rpms-system.zip. Thus, as you backup the user-data, you also backup the system-files resulting in a full backup.
For a backup using rsync over SSH, here is an example-script:
#!/bin/bash
rsync --progress --delete -rtv --max-size=4GB --modify-window=2 --exclude Downloads \
pi@rpms:/media/usbdata/user/* \
/media/$USER/<disklabel of backup-disk>/backup/user
sync
Disaster can come from anywhere: a broken Pi (very unlikely), a corrupt SD-card or a data-disk which gets broken. In each case, the solution within RPMS is very simple
Steps to get back on track:
You may possibly need to reconnect player(s)
Steps to get back on track:
if the hardware is damaged, obtain a new card, otherwise, use the same card
burn and install RPMS onto the card (see above for instructions)
now you are ready to go
You may possibly need to reconnect player(s)
In case of a server-based backup, you are 'lucky': b/c the backup-disk is an exact copy aka mirror of the data-disk and even of the same disk-type (ext4), you can simply swap them once the data-disk has been crashed.
Steps to get back on track:
usbbackup to usbdata
usbdata) from your local machineBy now, the backup-disk has been automagically changed into a data-disk and you can go on from the last backup that you made.
Note. As a bonus, you might rename the original usbdata-disk from usbdata to usbbackup and plug it into the Pi. Then you can do your backups again, as usual.
In case of a remote backup, you have more work to do:
Remember to make a backup to a new backup-disk immediately!
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!
master to develop branchssh 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 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 Installation of RPMS on a Pi
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-cachesAs 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.
~/source/rpmusicserverdevelop
cd ~/source/rpmusicserver # Examplegit checkout developcd ~/source/rpmusicserver # Examplersync -r ./* pi@rpmsdev:/tmp/rpmusicserver
rpmsssh pi@rpmsdev "sudo chmod +x /tmp/rpmusicserver/scripts/* && sudo /tmp/rpmusicserver/scripts/install-rp.sh"
rpmsNote. 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 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.
sudo apt-get install python3-pippip3 install -r <source-folder of rpmusicserver>/web-interface/requirements.txtcd <source-folder of rpmusicserver>/web-interface/apipython3 controller.pycd <source-folder of rpmusicserver>/web-interface/webpython3 controller.pyhttp://localhost:1080 http://localhost:5000curl http://localhost:5000Note. 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:
sudo apt install squeezelitesqueezelite -o default -z -n "Local"sudo kill $(ps -ef | grep squeeze | grep -v grep | awk '{print $2}')curl rpms:5000/api/GetApiListComing from any version below 1.0, you cannot migrate through the usual upgrade-command b/c the upgrade will introduce breaking changes which turn your system into a broken one. Furthermore, b/c we moved the OS from 32-bit to 64-bit, a new image-burn is needed.
(1) Burn a SD-card
(2) Convert your system
ssh pi@rpms "cat /media/usbdata/rpms/config/docker/syncthing/config.xml" > ~/synthing-config.txtssh pi@rpmssudo kill-dockersudo mv /media/usbdata/user/Publiek /media/usbdata/user/publicsudo mkdir /media/usbdata/user/music -psudo mv /media/usbdata/user/public/Muziek/* /media/usbdata/user/musicsudo rmdir /media/usbdata/user/public/Muzieksudo mkdir /media/usbdata/user/downloads -psudo mv /media/usbdata/user/public/Downloads/* /media/usbdata/user/downloadssudo rmdir /media/usbdata/user/public/Downloadstree -d -L 2 /media/usbdata/usersudo sed -i -e 's/Publiek/public/g' /media/usbdata/rpms/config/transcoder-settings.jsonsudo sed -i -e 's/public\/Muziek/music/g' /media/usbdata/rpms/config/transcoder-settings.jsoncat /media/usbdata/rpms/config/transcoder-settings.jsonsudo halt-server (3) Install the new SD-card, boot the Pi and finish the installation
(4) Check system if all is working well:
Optional
ssh pi@rpmssudo mv /media/usbbackup/user/Publiek /media/usbbackup/user/publicsudo mkdir /media/usbbackup/user/music -psudo mv /media/usbbackup/user/public/Muziek/* /media/usbbackup/user/musicsudo rmdir /media/usbbackup/user/public/Muziektree -d -L 2 /media/usbbackup/user # To check