Shoutcast relaying problems from di.fm

[sekhmet]

Hello, all...

I've been listening to a few of the wonderful streams at http://di.fm recently, and I've come to want to be able to listen to the stream on multiple computers on my private net (sitting behind a firewall). I figured that shoutcast relaying was the way to go for me, so I went about setting it up, but I'm having difficulties getting it right. I've searched around these forums quite a bit, but to no avail. This is on a Linux machine, BTW...

di.fm has a number of streams, for instance: http://di.fm/mp3/trance128k.pls and http://di.fm/mp3/hardtrance128k.pls

If you take a look inside those playlist files, you'll see something like this:

code:
[playlist]

NumberOfEntries=5

File1=http://205.188.209.193:80/stream/1003

Title1=D I G I T A L L Y - I M P O R T E D - Trance channel! (US Ultravox)

Length1=-1

File2=http://205.188.209.193:5190/stream/1003

Title2=D I G I T A L L Y - I M P O R T E D - Trance channel! (US Ultravox)

Length2=-1

File3=http://160.79.1.141:8000

Title3=D I G I T A L L Y - I M P O R T E D - Trance channel! (redirect to free server)

Length3=-1

File4=http://213.73.255.244:8000

Title4=D I G I T A L L Y - I M P O R T E D - Trance channel! (Netherlands, probably full)

Length4=-1

File5=http://193.201.220.87:8000

Title5=D I G I T A L L Y - I M P O R T E D - Trance channel! (Norway, probably full)

Length5=-1

Version=2

I figured that the third one there looked promising enough (no extra information at the end of the URL), so I tried using that for RelayPort and RelayServer. However, starting up the shoutcast server gave me this message:

code:
<01/03/03@11:08:55> [source] relay host returned error (HTTP/1.0 302 Found) [waiting 30s]

Taking a packet sniffer to the transaction, I noticed that, indeed, that URL was just sending a 302 message to redirect to "http://64.236.34.141:80/stream/1003" which is in the same format as the other URLS...

My basic problem is that I don't see where in sc_serv.conf I can define that I need to append "/stream/1003" to the end of the URL. All I have options for is the IP address and the port. Am I missing something major?

Thanks much for any help!

-sekhmet

[Tom]

You'll need to use one of the addresses that has a :. The : separates the IP and port. Also you should contact di and ask if them if you can do this or they may ban you.

Tom

[sekhmet]

Originally posted by Tom
You'll need to use one of the addresses that has a :. The : separates the IP and port. Also you should contact di and ask if them if you can do this or they may ban you.

Tom

Right, I'm aware of what the colon does... What do you mean by that? Every address on there specifies a port... I've tried using every IP in their playlist file (specifying the correct port in every case), and none of them have worked. The first two return 404 errors (not surprising, since my shoutcast server is sending a packet requesting "/" instead of "/stream/1003"), and the others return back with a 302 containing a redirect to a server in the form of "http://ipaddr:8000/stream/1003", which the shoutcast server doesn't know what to do with.

I did scour the DI forums for a bit before making my way over here; they seem to be generally all right with people doing relay-type-things, even offering some suggestions, but I figured it was more of a shoutcast issue than an issue with them... Their webcast is working all right, after all. As to legality, etc, I'm just going to be streaming this to a few computers around the house; I'll still be the only person using it, so they don't even have to worry about extra royalties or anything. Basically, I just want to save them bandwidth.

I've watched the packets go back and forth when connecting to, for instance, "http://205.188.209.193:80/stream/1003" with an mp3 player. The mp3 player sends what's basically an HTTP request to the server at that address, then the server sends a short little HTML snippet back to the MP3 player (using "ICY" headers instead of the usual), then a few more headers obviously meant for the player, and then starts streaming the data. I could upload a tcpdump capture if you'd like...

... what I evidentally need to know is how to get the shoutcast server to send the request *with* the "/stream/1003" at the end. As it is, it can only send "http://205.188.209.193:80/", which isn't a valid stream URL. And, like I said, the others without "/stream/1003" in them just send a 302, which the server doesn't grok.

[Tom]

RelayPort=8000
RelayServer=160.79.1.141

Tom

[sekhmet]

That's precisely what I have in my sc_serv.conf right now. When I run "sc_serv" it contacts the host at that port, then sends a request that looks exactly like this (copy-and-pasted from the packet I sniffed):

code:
GET / HTTP/1.0

Icy-MetaData:1

User-Agent:Shoutcast Server 1.9.2

To which 160.79.1.141 replies with the following (again, copy-and-pasted right out of my packet sniffer's window):

code:
HTTP/1.0 302 Found

Content-type:text/html

Location: http://194.226.44.30:8000



<HTML><HEAD><TITLE>Redirect</TITLE></HEAD>

<BODY>Click <a href="http://194.226.44.30:8000">HERE</A> for redirect

</BODY>

</HTML>

The shoutcast server doesn't know what to do with that... It invariably spits this message out on my console: "<01/03/03@14:08:40> [source] relay host returned error (HTTP/1.0 302 Found)" The actual IP address it gives there seems to rotate, because previous tries I made earlier in the day had a "/stream/1003" at the end. That IP address given there (194.226.44.30) only works sporadically, and I've tried connecting from a completely seperate host on a completely different network, just in case I was in a netblock that was blacklisted or something.

Now here's something strange; while starting up sc_serv a number of times while writing this (to make sure that I was being accurate about the IPs, etc), the server actually DIDN'T give me a 302 error for ONE of the times I tried to connect. So it must do some kind of round-robin thing where once the server is too busy it redirects out to other servers which are less busy.

Now that's all fine and good, I suppose, but that's only ONE time I've been able to connect to that server, and I've only been able to connect to the server given in the redirect once or twice.

All in all, the bottom three URLs given just don't seem to be a valid option. I assume from your responses that there's no way to get the shoutcast server to request "/stream/1003" at the end of the requested URL? From what I've seen from packets flying across my network, that's the only change that would need to happen. Instead of sending "GET / HTTP/1.0" it needs to send "GET /stream/1003 HTTP/1.0" I assume the shoutcast server source code isn't available anywhere, right?

[sekhmet]

As a reference, here's what the packet exchange looks like using one of the first two URLs. First my mp3 player sends:

code:
GET /stream/1003 HTTP/1.0

Host: 205.188.209.193

User-Agent: xmms/1.2.7

x-audiocast-udpport: 32778

And then the server sends back:

code:
ICY 200 OK

icy-notice1: <BR>This stream requires <a href="http://www.winamp.com/">Winamp</a><BR>

icy-notice2: SHOUTcast Distributed Network Audio Server/SolarisSparc v1.9.2<BR>

icy-name: D I G I T A L L Y - I M P O R T E D - European Trance, Techno, Hi-NRG...  we can't define it!

icy-genre: Trance Techno Dance

icy-url: http://www.digitallyimported.com

icy-pub: 1

icy-metaint: 0

icy-br: 128

icy-irc: #shoutcast

icy-icq: 0

icy-aim: N/A

There are a few extra headers in the request, but I'm guessing they're mostly optional...

[Tom]

The first two are using Ultravox and can not be relayed at this time with the DNAS due to the fact that they use a mount point. The three that end in a port number should be able to be relayed. What you are experiencing is the DNAS trying to roll you over to a back-up server since the server you requested is full. Try: http://193.201.220.87:8000 right now it has more than 100 spots open.

Tom

[peppert]

uh, yeah. don't relay ultravox streams. the only allowable downstreams are those we explicitly permit. sorry.