JReceiver Audio Server

hosting for the Rio and beyond

JReceiver is a servlet-based audio server which features tightly
integrated metadata indexing capabilities, browser-based management,
an XML-RPC interface and support for network-based MP3 players like the
Rio Receiver from Sonic Blue.

This is an open source project hosted at SourceForge and
licensed under a conventionally modified BSD
license.

In short, it's a rich, graphical client that presents your local and
JReceiver-based media collection in one convenient interface. There
are WebStart enabled links for you to try out on the page mentioned
above. Better yet, it's an open source project, so if you find it
useful (or if you find, ahem, bugs), please contribute!

He adds an update from the JavaOne conference: Nick R. and company have a
great demo showing his J2ME based JRec client and Mu all talking to
one JReceiver server. Excellent end-to-end Java story.

0.2.5 Alpha

16-May-2003

This is mainly a maintenance release which includes bugfixes for both
JReceiver and the Ptarmigan XML Media Parser.

It also supports recent Jetty releases. Logging configuration is
more conventional. Scanning is more efficient. And many other minor
changes as well.

Targeted for the next release is VBR support for Ptarmigan. JReceiver
will then be feature complete and you see a Beta followed by the
full 1.0 release.

Please test this release exhaustively. Try to isolate any defects
you find and report them to the SourceForge bugbase. Thanks!

0.2.4 Alpha

05-October-2002

Welcome to the world of heterogeneous music collections!

Gone are the days when your music collection had to conform to a single
format. No longer are you constrained to MP3 or even a lossy audio format.
Console players such as the Rio Receiver that have been able to play
MP3/WMA have been extended to support Ogg
Vorbis and the lossless FLAC
audio formats.

This release of JReceiver introduces the Ptarmigan Media Parser for
XML (http://ptarmigan.sourceforge.net)
which extracts various flavors of metadata (ID3v1,
ID3v2, Vorbis, etc.) from your audio files, including MP3, WMA, Ogg, FLAC
and four different kinds of playlists. It is now the primary means of
identifying the mime-type of music files and streams.

Also included is support for the new Jetty 4.1, which conforms to the
Servlet 2.3 container spec. Tomcat 4.1 compatibility is approaching and
may already have arrived.

Some performance enhancements as well, such as precompiled JSPs using
the new Jasper2.

0.2.3 Alpha

27-July-2002

This is largely a maintenance release to address problems that were
introduced as a result of the recent changes.

A few enhancements as well, including support for the Rioplay client,
WMA (Windows Media) tag parsing, FLAC mime-type support, a "home" button
on the status panel, and a few SDK changes as well.

0.2.2 Alpha

22-July-2002

Security has arrived with this 0.2.2 Alpha release of JReceiver!

The new security features are fairly comprehensive and go a long way
towards making JRec safe to use in an open network environment. Read the
details on these features below.

The JRec API has a new Menuing interface, allowing complex queries to
be specified in an abstract syntax independent of database implementation.
Read more about these changes on the sdk page.

0.2.0/1 Alpha

31-May-2002

The 0.2.0 Alpha release of JRec introduces a new control
architecture permitting the control of basic player functionality both
directly over a network connection or indirectly using an IR
emitter like the RedRat2.

The underlying server architecture has undergone an extensive
refactoring, consolidating redundant functionality, adding a
business-logic layer and paving the way for upcoming features.

Documentation is now available for Server installation on Windows 2000/XP.
Windows docs for installing Rio Receiver are likely forthcoming.

The JRec API has seen some changes as well, mostly in the area of
consistency made possible by the aforementioned refactoring.

Playlist XML import has been temporarily disabled due to some
changes in Struts, the web-application framework on which the manager app
relies.

audio/x-mp2 has been added to the list of supported mime-types.

Features

JReceiver aims to be a general-purpose audio server with a sophisticated
feature set and a development path that occasionally breaks new ground.

Architecture

Modular and n-tiered - JRec is structured with the goal that most new
functionality, such as a SOAP interface, may be added without the need
for major surgery.

Deep Metadata - by aggressively indexing ID3 tags and other music
metadata, JRec provides new and sophisticated ways of organizing
music through user-specified queries.

Open Interface - the core server functionality is exposed in an XML-RPC
interface to support a variety of different types of software and hardware
players. See the Developer's SDK for a
detailed look.

Menu-driven - the XML-RPC interface is geared towards software and
hardware clients seeking to navigate with ease over large music collections
in order to find the desired stream of music.

Open Standards - eschewing proprietary technology where none is called
for, the present implementation employs the Java™ Language,
Servlets, JavaServer pages, JDBC, XML and tools from Apache Jakarta and other open-source
projects. JRec itself is an open-source project.

Multi-environment - the JRec server is capable of living on a server
catering to remote clients, or living within a disk-based player,
playing to its own soundcard and possibly remote clients as well.

General-purpose Control Architecture - permits the direct
control of devices and players over a net connection via XML-RPC and
indirect control via IR emitters like the RedRat2. Control is presently
available through the web interface.

Music Management

Apart from supporting basic queries on artist,
album and genre, JRec provides a set of tools to specify playlists based
upon complex filters using standard SQL syntax.

Playlist Files - .m3u and .pls files are read by the scanner and
available to be retrieved by name, queried upon and combined with other
playlists.

Tree Playlists - permit you to specify folders and individual files
of music across multiple filesystems and assign a name and sort order.

Dynamic Playlists - these are playlists defined by a SQL query of tag
info and created on-the-fly when requested from a player. You can also
'embed' other playlists as well to modularize your entire music
collection.

'Station' Playlists - specify Shoutcast and other
external stream sources to play to your Rio Receiver or other JRec player.

Mime-type support - mime-type for each tune is now stored
in the database. This makes it possible for clients to view only those
formats which they support natively or through transcoding.

User-configurable sort order -- specify a default global sort order
or narrowly for a playlist. The sort defaults to "album.name, trackno."

Other Features

Standalone Use - a Rio Receiver is no longer necessary to
use JRec. You can now stream individual tunes and playlists to desktop
players like WinAmp, Zinf, RealOne, XMMS, etc.

Player Status -- status of all active clients interacting with the
server in a web-based panel

Transcoding - convert between audio formats in real-time
through the invocation of external transcoding programs. This permits
you to play music whose formats would otherwise not be supported by
your console player. Example: play .ogg streams on the Rio, which only
supports .mp3 and .wma.

Screen Shots

A view of the Manager Web Application

Downloads

Though JRec is still in 'alpha' it nevertheless has been updated on
a regular basis with stable releases. It may be downloaded NOW from
the links below:

Requirements

A Rio Receiver is no longer necessary to use JReceiver. You can now
stream individual tunes and playlists to desktop players like WinAmp, Zinf, RealOne, XMMS, etc.

The JReceiver Server presently requires a platform with a Java
runtime, version 1.3 or later, a web servlet container (Jetty during
the alpha development), a Java compiler (for JavaServer pages) and a
recent version of MySQL.

See the install documentation for more detailed requirements.

The Rio driver installation has additional requirements. Consult
its documentation,
local or
online.

Installation

The installation documents are presently geared towards installation on
Linux (and to some extent, Windows) and are slowly expanding to include
the broad range of platforms for which the server and its clients is
targeted.

If you have a question or experience a problem, please post to
this list rather than contacting the author directly. He
will be monitoring this list along with other users who can probably
answer your question more promptly.

Security

Features

The security features introduced with the 0.2.2 alpha release include:

Filter-based Authentication - found in the Manager Struts-based web
application. It checks every request to the webapp and redirects
unauthenticated users to a login page.

Role-based Authorization - Each user is assigned a role, which in turn
determines the user's access to resources. This includes querying the
database, controlling the scanner, adminstration, etc.

Access Control - each Role has a profile of methods in the JRec API it
can use. This is configurable through the Struts-based Manager app.
Access control is enforced with each request to the server.

Content Server - access to content requires minimal overhead
and is separate from the RPC security mechanism. To control access each
URL for a tune or playlist has embedded within it a random
alphanumeric string (e.g.,
"http://myserver.com/jreceiver/LJjw98wlw/Fly%20Me%20To%20The%20Moon.mp3").
These random strings are unguessable in a practical sense and are only
distributed to authenticated users.

Rio Driver - the Rio driver has an unsecured http interface used by
the Rio Receiver. To limit access, the user can configure a 'hosts allow'
list that defaults to "192.168. 10." to support Rios on most internal
networks.

Client Callbacks - when registering with the server, a client driver
can provide a set of credentials that will be sent along any requests the
server has of the client, such as for the status of players that the
client manages.

Known vulnerabilities

Security experts will tell you that no app is entirely secure. With this
in mind, some of the known problems with JRec:

Dictionary Attacks - for those users who don't change the default
passwords or choose simple ones, the authentication mechanisms of the
Struts-based Manager app and JRec API will be of little use.

IP Spoofing - for Rios on an open network, it's possible for a
hacker to pretend to be a client for the Rio Driver and make requests for
both metadata and content. The aforementioned 'hosts allow' setting
addresses this to some extent, as does the limited access control for the
'players' role. The only decent fix for this is to insist upon a secure
Rio client.

Obligatory Disclaimer - the author is not a security expert and may
have overlooked or not properly addressed all likely vulnerabilities.
Use at your own risk. Read the license.

Developer's SDK

For those interested in developing software or hardware players/clients
who might wish to use JReceiver as a server, check out the set of docs at:
onlinelocal.

Codebase

The CVS repository may be browsed here.
Code metrics are published onlinelocal.

Author & Acknowledgements

(in chronological order)

Reed Esau () is the
founder and lead of the project.

This work grew out of experimentation with Jeff Mock's Perl-based
implementation which he wrote to support his rebranded Rio from Dell.
See Jeff's excellent Rio hacking page at
http://www.mock.com/receiver/

Thanks to David Schuetz for his decoding of the display layouts for
the Rio Receiver and providing layouts for the 0.1.8 release. For more
details on the structure, see
here.

(0.1.9) Philip Gladstone (http://www.gladstonefamily.net)
is responsible for the streaming capture and transcoding support.

(0.2.0) Mark Harrison is responsible for the Windows docs for JRec
Server installation.

Current ReleaseAlpha 0.2.5 (@version-date@)

Supported Hardware

JRec's goal is to serve to any net-connected media player.

Rios are increasingly hard to find, but still available on eBay and from some distributors.

There may yet be a successor to the Rio, check the Rio
BBS for any announcements.

Like the Rio it's a net-based MP3 player, but whose hardware design and
software are fully open. You can even build your own from a kit. Check
out http://mp3elf.net to find out more.

The RedRat2 is the reference IR emitter for the JReceiver project. It can
connect to a COM port and control a Rio Receiver (or any other client that
supports the control interface) from across the room.

Adding a generic device driver to control other devices (like a DBS or A/V
receiver) through JRec is planned.

JRec can serve as the engine inside a home-built standalone player/jukebox
that sits alongside your other stereo components.

Write a driver in Perl, Python, Java, or other language of your
choice to support a keypad and serial display. Query JRec via XML-RPC to
build the menus and queue the stream to mpg123 which renders the music for the
sound card.