With spiffy new security features which go a long way towards making JRec usable on an open network.

http://jreceiver.sourceforge.net

Kewl!

Thanks again for all the hard work you've put into this. It is appreciated. And after a very quick test last night, it seems to work with RioPlay.

We now have a full end to end open source replacement for the original software. As Tony says .... Kewl !

Cheers

Dobbin.

This is largely a maintenance release that fixes a number of problems and adds a few enhancements.

27-Jul-02 - 0.2.3
Enhancement: now supports WMA metadata parsing and play to the std rio client
Enhancement: now supports RioPlay client
Enhancement: added basic mime support for serving/transcoding flac
Enhancement: upgraded PlaylistWriter capabilities to write PLS, M3U or ASX
Enhancement: Refactored mime-type handling
Enhancement: added 'home' button to status panel (so that you don't need main window open)
Fix: FtuneRec and FplaylistRec now pass timestamps in IS0-8601 format
Fix: recurrence of roots-with-same-last-name problem
Fix: Transitioned several 'edit' forms to request-oriented rather than session-oriented
Fix: station playlist can now handle direct entry of icecast url
Fix: tag encoding now uses dynamic mime for the driver (to accommodate xcoded sources)
Fix: improve desktop play by adding flush() and timing out on writes
Fix: added non-blocking stream writer to ContentEngine/RioHostContent to avoid resource leaks

might be a "RTFM" question, but does jreceiver support more then one receiver at the same time?
-mark

I haven't tried yet, but I think all you need to do is set up another tftpboot directory (I'm using wiindows) for each reciever's ip address.

Greg

...is this a quick-guide somewhere for w2k setup?
actually, how well does the shoutcast streaming support work?

Yes, JReceiver supports multiple RIOs. I've used three at once, and I think some people have used up to 6.

The Shoutcast streaming is pretty good, but it's not pulling out the song titles and displaying them in the Rio. I think one problem with that might be that there's no way to tell the rio to "refresh" its display. And since it pulls the entire playlist at once, you can't simply update a server-side "virtual playlist" with the next song and expect the Rio to find that when it finishes the current song.

At least that's the way I understand it -- it's been months since I've had time to hack the Rio or JReceiver...

But, anyway, Shoutcast music comes through great. And someone's playing with RealAudio conversion to MP3 (which would be good, 'cause then I could get some local radio stations). Better yet would be a linux-based radio receiver that does internal mp3 streaming from an FM antenna, but I haven't even looked into that yet.

dschuetz wrote:

> I think one problem with that might be that there's no way to
> tell the rio to "refresh" its display. And since it pulls the
> entire playlist at once, you can't simply update a server-
> side "virtual playlist" with the next song and expect the Rio
> to find that when it finishes the current song.

That's correct. The standard client supports only static playlists that it fetches prior to play. The size of those playlists is limited by available memory -- typically 2k tracks.

Streams are handled as a single 'tune'. Because the standard client only pulls tag info at the start of the tune, that's all we can display.

The coming release of jrec will feature metadata notification callback so that players can display tag info from a stream as it becomes available.

--Reed http://jreceiver.sourceforge.net

JReceiver supports multiple Rios on quite old hardware, in fact.

I run 5 Rios on a P2-300 server, with 192Mb RAM. The PC does this without breaking into a sweat.

Mark in England