Replacement Client & Server code - Working...

After a lot of time spent, I've finished what I consider a "working" replacement client for the rio, as well as a simple server. There's a binary distribution for those of you who dont want to bother compiling it yourselfs. There are a lot of features missing, but the infrastructure is in place to make adding them easy.

I was hoping to get a couple people to test out the distribution to see if it works for them, or if there are any problems.

http://www.reza.net/rio/rrr.html

Thanks,
Reza

Wow.

I haven't tried this out (don't have a linux box to try it with), but... Wow.

Hi there... just stumbled across your software. Haven't tried it yet. Would the server work on a Windows box?

I've been thinking about this project for a little myself. What would be involved with adding an RTP RTSP or ICECAST compatible HTTP streaming client on the rio receiver, so that one could serve MP3s from a Darwin-based Streaming Media server? This is the open source version of Apple's project, and the server runs on Linux, Solaris, and Windows. By getting it to work with Darwin you wouldn't have to diddle too much with the server side of the software (except for the UPNP and NFS stuff).

Just a thought.

Cheers,
Marc

Another question: does your code run on top of RIO's provided linux kernel? Well, maybe I should just take a peek, huh?

By getting it to work with Darwin you wouldn't have to diddle too much with the server side of the software (except for the UPNP and NFS stuff).

I get the feeling that streaming media would actually be easier to implement in the server, rather than trying to implement it on the player side.

Since we have things like JReceiver working already, why can't we just have the server software grab some streams from the internet and supply them as available playlists to the Receiver?

(See, the player already streams from the server, it's just a question of formatting the data in such a way that the Receiver knows what to do with it.)

>See, the player already streams from the server...

In what format is it streamed?

>I get the feeling that streaming media would actually
>be easier to implement in the server, rather than
>trying to implement it on the player side.

I see. You are suggesting that on the server side ICECAST is translated to whatever the receiver can handle.

In what format is it streamed?

Details can be found here.

You are suggesting that on the server side ICECAST is translated to whatever the receiver can handle.

Exactly. There have already been discussions about doing this, if I recall correctly.

I read about that format before, which was informative.

However, what I want to know is the format that is used to stream the MP3 data to the receiver? Is it just a single HTTP connection that sucks down the full binary?

The Receiver makes a separate HTTP request to the server for each chunk of the MP3 file. I think it requests 32k at a time.

It should work on their kernel, but I don't see what the benefit of doing that is. My motivation for not using it is that there will be no software written by Rio on the receiver when I'm done.

I really don't see how it'd be easier to implement it server side. And you miss out on a lot of advantages, such as being able to turn off your computer, and still listen to streaming audio from the internet. In any case, It shouldn't take too long to get it to work, I just need to stop working on my other projects long enough to do some more work on this one.

I can't comment about your code, but with our original protocol, it turns out to be easier to stream directly to the Receiver -- there's a build around here somewhere that'll stream shoutcast directly.