#221571 - 03/06/2002 19:11
Replacement Client & Server code - Working...
|
newbie
Registered: 29/03/2002
Posts: 35
Loc: San Francisco Bay Area
|
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
|
Top
|
|
|
|
#221572 - 04/06/2002 04:19
Re: Replacement Client & Server code - Working...
[Re: reza]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
Wow.
I haven't tried this out (don't have a linux box to try it with), but... Wow.
|
Top
|
|
|
|
#221573 - 01/07/2002 23:02
Re: Replacement Client & Server code - Working...
[Re: reza]
|
newbie
Registered: 01/07/2002
Posts: 37
Loc: Seattle, WA, USA
|
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
|
Top
|
|
|
|
#221574 - 01/07/2002 23:14
Re: Replacement Client & Server code - Working...
[Re: reza]
|
newbie
Registered: 01/07/2002
Posts: 37
Loc: Seattle, WA, USA
|
Another question: does your code run on top of RIO's provided linux kernel? Well, maybe I should just take a peek, huh?
|
Top
|
|
|
|
#221575 - 01/07/2002 23:16
Re: Replacement Client & Server code - Working...
[Re: mef]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
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.)
|
Top
|
|
|
|
#221576 - 01/07/2002 23:39
Re: Replacement Client & Server code - Working...
[Re: tfabris]
|
newbie
Registered: 01/07/2002
Posts: 37
Loc: Seattle, WA, USA
|
>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.
|
Top
|
|
|
|
#221577 - 02/07/2002 09:34
Re: Replacement Client & Server code - Working...
[Re: mef]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
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.
|
Top
|
|
|
|
#221578 - 02/07/2002 14:52
Re: Replacement Client & Server code - Working...
[Re: tfabris]
|
newbie
Registered: 01/07/2002
Posts: 37
Loc: Seattle, WA, USA
|
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?
|
Top
|
|
|
|
#221579 - 02/07/2002 18:49
Re: Replacement Client & Server code - Working...
[Re: mef]
|
carpal tunnel
Registered: 10/06/1999
Posts: 5916
Loc: Wivenhoe, Essex, UK
|
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.
_________________________
Remind me to change my signature to something more interesting someday
|
Top
|
|
|
|
#221580 - 03/07/2002 04:39
Re: Replacement Client & Server code - Working...
[Re: mef]
|
newbie
Registered: 29/03/2002
Posts: 35
Loc: San Francisco Bay Area
|
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.
|
Top
|
|
|
|
#221581 - 03/07/2002 04:46
Re: Replacement Client & Server code - Working...
[Re: tfabris]
|
newbie
Registered: 29/03/2002
Posts: 35
Loc: San Francisco Bay Area
|
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.
|
Top
|
|
|
|
#221582 - 03/07/2002 05:16
Re: Replacement Client & Server code - Working...
[Re: reza]
|
carpal tunnel
Registered: 18/01/2000
Posts: 5683
Loc: London, UK
|
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.
_________________________
-- roger
|
Top
|
|
|
|
|
|