search

markbaaijens / rpmusicserver

Transform a Raspberry Pi in a music server with LMS (Squeezebox), Samba, transcoder, etc.
GNU General Public License v3.0
5 stars 0 forks source link

readme

RP Music Server

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
Installation of RPMS on a Pi
Troubleshooting
Folder mapping
Update RPMS
Transcoder
Backup
Disaster Recovery
Development
Migrating to 1.0

System requirements

Installation of RPMS on a Pi

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.

Check your network if local DNS works

To detect if your network supports local DNS, execute the following command in a terminal:

Check for output:

Steps to install RPMS on your Pi

Folder mapping

For several services within RPMS, 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 case have to be documented.

Mapping from virtual folder to fysical folders:

So when working the inside of the docker-infrastructure, either LMS or SyncThing, refer to the virtual folders.

Troubleshooting

Pi/rpms cannot be reached on the network

Sometimes the pi is not visible in the network, either by hostname rpms or even by ip-address.

If everything fails (no hostname shown for pi, multiple ip-addresses for hostname, not able to ping on hostname, etc.), try:

Pi/rpms can only reached by ip-address

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 accesible 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 wil 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.

Reconnect players after LMS migration

When migrating from an existing LMS-server or upgraded 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 RPMS

Update your RPMS-server by the web-interface:

Note: update is disabled when there is no newer version found.

Transcoder

For transcoding your lossless files (flac) into lossy ones (ogg or mp3), take the following steps. From then on, every hour at 20 minutes, file transcoding will take place and lossy-files will automagically appear in the given lossy-folder!

Notes

Backup

You 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.

Server-based backup

The advantage of the server-based (local) backup is that the resulting backup is a 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 it self, thus a server-based backup.

Viewing backup-data on the usbbackup-disk

In 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.

For viewing online, the backup-disk has to be attached to the Pi. Simply point your file esplorer to smb://rpms/Backup and than you can view all the files on that disk.

For viewing offline, the backup-disk has to be attached to your own PC or laptop. The backup-disk is formatted as ext4 so this format is natively supported on Linux, thus being plug-and-play. Windows however requires additional drivers for viewing ext-drives. And worse, MacOS does NOT support ext4 at all! (despite extX being open-source/open-standard).

Remote backup

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 a 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 Recovery

Disaster can come from anywhere: a broken Pi (very unlikely), a corrupt SD-card or a data-disk which get broken. In each case, the solution within RPMS is very simple

Broken Pi (very unlikely)

Steps to get back on track:

You may possibly need to reconnect player(s)

Corrupt SD-card

Steps to get back on track:

You may possibly need to reconnect player(s)

Data-disk crash

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:

By now, the backup-disk has been automagically changed into a data-disk by now and you can go on from the last backup that you made.

In case of a remote backup, you have more work to do:

Remember to make a backup to a new backup-disk immediately!

Development

Update from another git branch

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. As a result, an indicator VersionOverride pops up in the web-interface.

Note that once VersionOverride is active, CurrentVersion and AvailableVersion do not play a role anymore.

To switch version from master branch to e.g. develop branch:

Returning to the master branch version simply delete the update-branch.txt text file:

Build development version with separate hostname

The rpmsdev hostname is used in this build

List of API requests

Migrating to 1.0

Coming from any version below 1.0, you cannot migrate through the usual upgrade-command b/c the upgrade contains breaking changes which turn your system into a broken one.

Steps to migrate to 1.0

(1) Burn a SD-card

(2) Convert your system

(3) Install the new SD-card, boot the Pi and finish the installation

Optional