JReceiver: Rio FAQ

You may also want to check out the server-faq.

What audio formats do each of the clients support natively? What features does each have?

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

DisplayServer** Yes Yes No No No Yes Yes http://fvgestel.dyndns.org/receiver/ http://groups.yahoo.com/group/jreceiver_user/files/

Reza's Rio Receiver Yes No Yes No Yes No No http://www.reza.net/rio/rrr.html

RioPlay Yes No Yes Yes Yes No No http://rioplay.sourceforge.net/

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
DisplayServer**	Yes	Yes	No	No	No	Yes	Yes	http://fvgestel.dyndns.org/receiver/ http://groups.yahoo.com/group/jreceiver_user/files/
Reza's Rio Receiver	Yes	No	Yes	No	Yes	No	No	http://www.reza.net/rio/rrr.html
RioPlay	Yes	No	Yes	Yes	Yes	No	No	http://rioplay.sourceforge.net/

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

Why use port 8080 to support the Rio's queries?

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.

How does the Rio Receiver connect with a host server?

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

http://HOSTNAME/descriptor.xml\n

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

/tftpboot/HOSTNAME

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

http://HOSTNAME:PORT/descriptor.xml\n

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

Why is the receiver's IP in the NFS share name?

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

Why use DHCP if you require a fixed IP?

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.

main install faq rio redrat sdk