You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of the SharedData feature relies upon creating and sharing an CIFS/NFS netwrk share of the Master (server) rAudio installation. Prospective clients then mount this network share giving access to the music library and other rAudio components provided by the master installation. This works up to a point but has recently caused some issues where the clients struggle to attach the network share in such a way as to allow the functionality to work. I have an existing ticket open (#1966) where I have identified the issues I am seeing with the current approach.
This has led me to explore (again) the functionality of MPD and its satellite server capabilities as documented here:
This, in theory, seems to simplify the SharedData setup.
In the code shown below, based on my own experients, the Server is referred to RAOffice / 192.168.86.31 and the clients would have various hostnames along the lines of rAudio-1 / 192.168.86.35, rAudio-test / 192.168.86.37 etc
My test implementation of this requires:
A rAudio installation to be designated as the master or 'Server' installation. This should be a standard rAudio installation preferably using a wired connection but wireless would still work - in my case this is based on an RPi3B+. The only change to this setup is a minor change to the configuration of the '/srv/http/data/mpdconf/mpd.conf' file:
to include a cache_directory parameter as shown above
The client(s) are also based on a standard rAudio installation, in my case these are a mix of RPi Zero2W and RPi3A+, but each would also need a revised '/srv/http/data/mpdconf/mpd.conf' as shown here:
# Note the proxy plugin here
database {
plugin "proxy"
host "192.168.86.31"
port "6600"
}
playlist_directory "/srv/http/data/playlists"
# Music Library setup - NFS/SMB details as per my own installation
#music_directory "nfs://192.168.86.250/export/music/"
#music_directory "smb://192.168.86.250/music/"
music_directory "/mnt/MPD/"
include_optional "curl.conf"
# file - plug and play content
include_optional "output.conf"
include_optional "bluetooth.conf"
# link
include_optional "autoupdate.conf"
include_optional "camilladsp.conf"
include_optional "cdio.conf"
include_optional "custom.conf"
include_optional "ffmpeg.conf"
include_optional "fifo.conf"
include_optional "httpd.conf"
include_optional "normalization.conf"
include_optional "outputbuffer.conf"
include_optional "replaygain.conf"
include_optional "snapserver.conf"
include_optional "soxr.conf"
include_optional "soxr-custom.conf"
The main changes being to the database parameter section and the addition of a new 'music_directory parameter. Although the wiki example shows NFS/SMB examples for this, I think this could easily be mapped to the existing rAudio music library location.
The rAudio settings (counts, webradios, playlists etc) may also need to be made available to the client(s). I think the simplest way to achieve this is to do away with the existing SharedData NFS/CIFS share and replace it with a simple RSYNC process which could be activated when a Database Update is initiated on the Server system. This would require Rern to include the RSYNC executable in the rAudio image build. A simple user process will be needed to copy over the necessary setting from the Server to each client system(s). This would be run from the Server installation and could look like:
Similarly the 'exclude.txt' file should be a simple text file and could contain those directories/files which should NOT be copied to the client system(s):
This is the point where my current knowledge limits how I can take this further without some additional help. I can run the rsync process manually but I do not know how to enable a password to be passed into the process to allow it to be run as part of the rAudio application ie when the Server Library is updated. Similarly, I have experimented with the contents of the include.txt/exclude.txt files - the current contents may, or may not, be suitable but I am happy to be corrected on their contents. In addition it may be necessary to provide some sort of user interface to allow the list of clients to be updated by the rsync process and the contents of the include.txt/exclude.txt files to be maintained. The best place to hold the include.txt/exclude.txt files needs to be agreed.
I currently have the above working on my test rigs. I realise it will get lost if I apply any updates to any of the test systems involved so far.
This idea seems to have some benefits:
its relatively simple to implement with minimal changes to the base rAudio application.
the Music Library database is held on one system and uses well know processes to make the information available to the clients.
clients can be easily removed from the overall implementation without affecting any other client.
using rsync removes the need for the internal NFS/CIFS share and the complicated moves when the SharedData option is enabled/disabled. No permissions issues etc
There are however some issues that still need to be overcome:
how to run the rsync processes easily from within rAudio.
the contents of the include.txt/exclude.txt files and their final location need to be confirmed.
a new UI needs to be developed to manage the rsync process and the config files it uses.
I would be interested in any comments anybody out there might have.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
FOR DISCUSSION
The current implementation of the SharedData feature relies upon creating and sharing an CIFS/NFS netwrk share of the Master (server) rAudio installation. Prospective clients then mount this network share giving access to the music library and other rAudio components provided by the master installation. This works up to a point but has recently caused some issues where the clients struggle to attach the network share in such a way as to allow the functionality to work. I have an existing ticket open (#1966) where I have identified the issues I am seeing with the current approach.
This has led me to explore (again) the functionality of MPD and its satellite server capabilities as documented here:
https://wiki.archlinux.org/title/Music_Player_Daemon/Tips_and_tricks#Music_streaming_with_the_satellite_setup
This, in theory, seems to simplify the SharedData setup.
In the code shown below, based on my own experients, the Server is referred to RAOffice / 192.168.86.31 and the clients would have various hostnames along the lines of rAudio-1 / 192.168.86.35, rAudio-test / 192.168.86.37 etc
My test implementation of this requires:
to include a cache_directory parameter as shown above
The main changes being to the database parameter section and the addition of a new 'music_directory parameter. Although the wiki example shows NFS/SMB examples for this, I think this could easily be mapped to the existing rAudio music library location.
the 'include.txt' file should be a simple text file and could contain only those directories/files to be copied to the client system(s):
data/webradio
Similarly the 'exclude.txt' file should be a simple text file and could contain those directories/files which should NOT be copied to the client system(s):
This is the point where my current knowledge limits how I can take this further without some additional help. I can run the rsync process manually but I do not know how to enable a password to be passed into the process to allow it to be run as part of the rAudio application ie when the Server Library is updated. Similarly, I have experimented with the contents of the include.txt/exclude.txt files - the current contents may, or may not, be suitable but I am happy to be corrected on their contents. In addition it may be necessary to provide some sort of user interface to allow the list of clients to be updated by the rsync process and the contents of the include.txt/exclude.txt files to be maintained. The best place to hold the include.txt/exclude.txt files needs to be agreed.
I currently have the above working on my test rigs. I realise it will get lost if I apply any updates to any of the test systems involved so far.
This idea seems to have some benefits:
There are however some issues that still need to be overcome:
I would be interested in any comments anybody out there might have.
Chris
Beta Was this translation helpful? Give feedback.
All reactions