You may also want to check out the server-faq.
Each of the clients has their own set of supported features. One has its own applet (DisplayServer) and two have their own web interfaces (RRR and RioPlay).
Consult each client's webpage for a rundown of its latest features.
A list of the features as they apply to JRec:
|Client||Native MP3||Native WMA||Native FLAC||Native OGG||Native ShoutCast||Integrated Control*||Integrated Status||Where to find it|
|Standard||Yes||Yes||No||No||No||No||Yes||on the CD which ships with hardware|
|Reza's Rio Receiver||Yes||No||Yes||No||Yes||No||No||http://www.reza.net/rio/rrr.html|
* Integrated Control - this refers to clients whose control interface has been integrated into the Rio Driver. Both RRR and Rioplay have web interfaces independent of JRec which may offer control.
** DisplayServer - the receiver.arf patch dated February 2002 had a problem with dropped socket connections for the control interface, both from its own applet and to jrec, requiring a Rio reboot. The recent version may have fixed this, but I haven't tried it yet.
Note that the above table describes native support for these formats. It's usually possible to transcode to a supported format, such as ogg->mp3 for the standard client.
Configure JRec for the client from Rio Settings (requires 'admin' login). Make sure to restart JRec after changing the settings.
The webapps of JReceiver can be independently configured to run on any ports you choose. By default they run on 8080, in part to avoid conflicting with the port 80 used by most web servers. It is also the default port of the Jetty web server described in the installation tutorials.
When powering up, the Rio Receiver first requests an IP address from a DHCP server.
Once it has an IP, it broadcasts a SSDP request on port 21075 seeking a server capable of providing an NFS share for which it can boot from. Available host servers respond with their IP in the following format
where HOSTNAME is the host server IP.
Once the Rio has obtained the server's IP, it then queries the server's portmapper to identify the port to which to mount an NFS share.
The Rio will then mount an NFS share on the server at
where HOSTNAME is the IP dotted quad that was assigned to the Receiver.
It then boots into Linux from files in this share.
Following this it makes a second SSDP broadcast seeking a content source. The server responds with an IP:PORT in the format
where HOSTNAME is the server IP and PORT is the port from which http requests will be made for both queries and the audio data itself.
The Receiver then looks for a DNS server in the /etc/resolv.conf of the NFS share. (TODO: investigate this.)
It finally queries the server for tag information -- any tag. Presumably the ID3 information of the first available MP3.
Connecting to the proprietary Win32 server differs somewhat because that server provides the DHCP and NFS servers and can make more assumptions. For more info, see BOOTING.TXT on the Windows distribution from Sonic Blue
The designers of the Rio presumably wanted to be careful not to conflict with existing NFS shares. This isn't an issue when the Rio is mounting an NFS share from its proprietary Windows host where a non-standard NFS port is used, namely 21078. The NFS share name name can be anything they want, and they choose the simple '/export/mercury'.
That '/export/mercury' might conflict if connecting to an NFS server that may be used for other purposes. To avoid a conflict, it insteads relies on a unique '/tftpboot/HOSTNAME' where hostname is a fixed IP address assigned to the Receiver.
(A better approach might be for the Rio to receive the NFS share name in the initial SSDP reply when it receives the server IP. Perhaps this will be fixed in a future version of the Rio client software.)
The Rio Receiver relies on a DHCP server to discover its IP assignment on
the network, be it a fixed IP or dynamic one. In this case it's fixed
because of the share name problem mentioned in the previous question.