SHOUTcast DNAS 2 Beta v0.1

[SC_faisal]

Presenting the first Beta point-release of what will be the next-generation of SC_SERV SHOUTcast DNAS broadcasting server! This drop is the result of the SHOUTcast broadcasting community's list of feature requirements over the years.

The goal of SC_SERV2 is to provide enhanced serving features and access to the new yp2 infrastructure (in development)
while maintaining as much backward compatibility with the previous sc_serv as possible.

Download Link >> http://download.shoutcast.com/beta/s...a_02232010.zip

Release Notes:

1) Serve multiple streams from a single server instance
2) Relay multiple streams from a single server instance
3) Multiplex all server activity through a single IP port.
4) Shoutcast 2 wire protocol support for sources, relays and clients
5) Repackaging of Shoutcast 1 and Shoutcast 2 data as appropriate for the connecting client(s)
6) yp2 infrastructure support

To take advantage of these new features you will also need the following:

1) sc_trans version V2 B38 or higher: http://forums.winamp.com/showthread....hreadid=317229

2) authorization hashes (register as a broadcaster in the new infrastructure and you will be issued the necessary hashes) - COMING SOON!

sc_serv must be configured to use the yp2 infrastructure to take advantage of the multiplexing and multiple stream support. The original yp interface had no means of
expressing multiple streams from a single port.

The yp2 interface is still in development and will be released soon! Stay tuned for updates.

If you are going to connect multiple sc_trans instances to sc_serv, you must use the Shoutcast2 protocol.
The original Shoutcast protocol had no means of specifying a stream ID. Clients connecting to the
server do not need Shoutcast2 support, since sc_serv will repackage the stream data and metadata for them as appropriate.


Comments / bug reports / feedback / feature requests welcome and encouraged!

Thanks!
- Neil and the SHOUTcast team.

[Nick@ss]

Good news all round,

Well done and a big thanks to the Shoutcast team,

Im sure this will be a good discussion point.

[chuckeh]

Great news! Will test the new version asap!

[Greg_E]

#1- good
#6- good

YP2 #2 - good

Does this require a different encoder? For those of us that have paid for an encoder this could be a bit of a problem.

If it works with my current encoders, I can throw it on something and give it a test since I have a couple encoders that are not used, and assuming that it runs on Windows.

[smoothbeats]

No more support for 7.html stats? I have no complaints about XML stats, but it was nice having an option that didn't require hardcoding the admin password into data collection scripts.

[SC_faisal]

Originally posted by smoothbeats
No more support for 7.html stats? I have no complaints about XML stats, but it was nice having an option that didn't require hardcoding the admin password into data collection scripts.

7.html will be deprecated in SC_SERV2. We are trying to move towards standardized broadcaster server "APIs" and stats access. 7.html was a hack anyway. ;-)

f.

[chuckeh]

Good decision!

Stats faking was a massive problem to the old YP and I hope it can be fixed with new sc_serv forever

[caraoge]

Great :-)

[Brutish Sailor]

This is ironic, because I was JUST making a joke this day would never come 4 days ago.

1-3 = Mount points? Zien! No more running port 80 streams from root! Time to drop IC2.

[jaromanda]

What impact, if any, does DNAS 2 have on nsv streaming?

[bored_womble]

i have to say, at the moment a little underwhelmed .... hopefully being the first drop this is just the basics and much more to come.

BW

[SC_faisal]

Originally posted by bored_womble
i have to say, at the moment a little underwhelmed .... hopefully being the first drop this is just the basics and much more to come.

BW

Yep - this is only a 0.1 release... Would love to hear your feedback and wish list of what we should focus on for oncoming releases.

Let us know!
f.

[smoothbeats]

Originally posted by SC_faisal
7.html will be deprecated in SC_SERV2. We are trying to move towards standardized broadcaster server "APIs" and stats access. 7.html was a hack anyway. ;-)

f.

I would like to see a way to retrieve server stats without having to pull that giant XML feed. Our main reason for pulling stats from the 7.html file rather than XML is because of the amount of data transferred. For an instance of sc_serv with 100 listeners, this means the difference between 419 bytes (7.html) and 26kb (xml) per request, a factor of 60. Multiply this by 20 servers that are queried once every 2 minutes, and the difference in the amount of data transferred is staggaring.

7.html = 173MB/month
index.html (screen scraper) = 2.7GB/month
xml = 11GB/month

While this amount of data is relatively trivial compared to the amount of bandwidth used by the streams themselves, it still seems silly to transfer 11GB of xml data when 7.html was able to accomplish the same thing in 1/60th the amount of data transferred.

Perhaps an alternate xml feed with just basic stats?

[Brutish Sailor]

Ok, I guess it isn't really mount points.

In your example:

stream config example

This server is providing three different streams for my station, and is
also relaying my friend's station

streamid_0=2
streamauthhash_0=abcdef
streampath_0=/bitrate/128

streamid_1=3
streamauthhash_1=abcdef
streampath_1=/bitrate/64

streamid_2=4
streamauthhash_2=abcdef
streampath_2=/bitrate/24

streamid_3=5
streamauthhash_3=aaaabbbbcccc
streampath_3=/headbash/relay/extra
streamrelayurl_3=http://foo.bar.whatever:80/stream/1074


Ok so if you are not using mount points to connect stream to server for multiple streams/single server, Im guessing the server is set to recognize the streamauthhash, and sets that stream as a separate relay for multiple streams/single server?

[nradisch]

Sorry, I couldn't follow your question.

--Neil

[Brutish Sailor]

I guess what Im asking is how the server passes a file out for the stream/ how do connect the source to the stream when their is multiple streams on the same server.

I know with IC2 you have mount points, which are sub directories of the IP.

It doesn't appear that the stream goes to a mount point, So with that being said, how is it that the server recognizes different sources, and what does the file, that server gives to the listening client, do that causes it to know the difference between different streams on the same IP?

[nradisch]

Okay, I think I understand your question.

In sc_trans set

outprotocol=3
uvoxstreamid=stream id specified in sc_serv config file

since these options in sc_trans are "multi", you can have a single sc_trans generate multiple streams for an sc_serv. For example

outprotocol_0=3
uvoxstreamid_0=5
outprotocol_1=3
uvoxstreamid_1=12

etc.

If you use the old shoutcast protocol (outprotocol=1 which is the default in sc_trans) then you can only attach one of them to sc_serv since there is no way to discriminate streams.

--Neil

[Brutish Sailor]

Got it. Thanks.

[bored_womble]

Originally posted by SC_faisal
Yep - this is only a 0.1 release... Would love to hear your feedback and wish list of what we should focus on for oncoming releases.

Let us know!
f.

so looking through the code it appears to be a completely different code base to SC1 which I suppose is not a surprise but means a couple of things need to be thought about

i) Some method to be able to get simple track information. It has been mentioned, so 7.html, perhaps not this format but say a simple URL get which provides this information such as

http://10.1.1.1/index.html?item=track

would give back the current track name ? then people could get items as they need without too much bandwidth.

ii) it appears you may have some bitrate management code in the pipeline it would be good to hear about it. This may of course just be UVOX specific.

iii) The UVOX specification allows listener authentication are you going to implement that ? So people who switched to Icecast for listener authentication can switch back to SC2.

iv) some method to 'template' the index.html. This will either allow people to blank it out or provide their own skin to it, so remove the dubious requests for changing the index file.

v) Are you going to make available the UVOX specification so people can write clients rather than just using Sc_trans2 ?

I await the next drop Good stuff though, a little life in SC yet

BW

[dotme]

It's exciting to see movement on this. Here's my short (for now) wishlist, along with a couple of questions...

1) Legacy encoder support would be important for a lot of people I think (in = portnumber, out = mount point)
Example:
Encoder connects on http://1.2.3.4:5678, listener connects on http://1.2.3.4:80/5678

Why? No offense, but sc_trans is well beyond the capabilities of non-technical users - heck, I can't even figure it out, and broadcasters have considerable money already invested in DJ software like SAM Broadcaster, Station Playlist and dozens of other packages out there. If I want to offer a 128k stream with audio processing, I don't want it "transcoded" at all. I want to push it to the server, end of story.

2) Authentication support for password protected/subscription streams would be cool. Something like the way Icecast currently supports it today. Listener is challenged, and provides username/pass. Shoutcast server then issues the call to a broadcaster website script URL, which "acks" or "naks" the connection attempt.

My questions...

1) Can you add/delete objects in the STREAM CONFIGS area "on the fly" without a restart of the core exe?

2) Can you specify max listeners, stream PW etc, on a per-stream basis?

3) Can SC2 RELAY a private SC1 server and be YP2 compatible that way?

[jaromanda]

Originally posted by bored_womble
v) Are you going to make available the UVOX specification so people can write clients rather than just using Sc_trans2 ?

I wonder if http://ultravox.aol.com/ (includes spec and reference apps) is at all relevant to the "uvox 2.1" protocol in sc2?

[bored_womble]

Originally posted by jaromanda
I wonder if http://ultravox.aol.com/ (includes spec and reference apps) is at all relevant to the "uvox 2.1" protocol in sc2?

#

it does ... but it has not been updated since 2004 .... I am guessing there has been some changes since then ...

BW

[nitromix]

Hello,

I like to know where i can find some example of config file for SC_SERV2. I look on documentation and there is not do clear for me how is working (source, relay, etc ...)

Thanks

[Greg_E]

How often are builds going to be released? Is it going to be a "when we have spare time" or is it going to be every XXX weeks?

[DaZilertaler]

today i gave the new beta a go on win7
i have buffer problems on song change
2010-03-01 14:19:12 I msg:[admincgi]title update [Susanna And The Magical Orchestra - It�s A Long Way To The Top]
2010-03-01 14:19:15 E msg:Bad UTF-8 code (92) at position 5f
2010-03-01 14:19:12 E msg:Failure converting filename to metadata Bad UTF-8 code (92) at position 26
2010-03-01 14:19:12 E msg:Failure converting filename to metadata Bad UTF-8 code (92) at position 26


a sc_serv config example would be handy i think i'm doing something wrong

have a nic day

[SC_faisal]

Originally posted by Greg_E
How often are builds going to be released? Is it going to be a "when we have spare time" or is it going to be every XXX weeks?

We hope to release one when we have enough bug fixes / new features. Looking forward to a new release soon...

f.

[nradisch]

Your playlists must be valid UTF-8 and any metadata embedded in the audio files must also be valid UTF-8. sc_serv and sc_trans do not accept locale based character sets.

--Neil

Originally posted by DaZilertaler
today i gave the new beta a go on win7
i have buffer problems on song change
2010-03-01 14:19:12 I msg:[admincgi]title update [Susanna And The Magical Orchestra - It�s A Long Way To The Top]
2010-03-01 14:19:15 E msg:Bad UTF-8 code (92) at position 5f
2010-03-01 14:19:12 E msg:Failure converting filename to metadata Bad UTF-8 code (92) at position 26
2010-03-01 14:19:12 E msg:Failure converting filename to metadata Bad UTF-8 code (92) at position 26


a sc_serv config example would be handy i think i'm doing something wrong

have a nic day

[Klausi2007]

Is it possible to relay a 1.9.8 server without yp2 compatibility?

When i try "relayport" and "relayserver", the sc_serv ends up there:

shoutcast2beta# ./sc_serv sc_10666.conf
2010-03-01 21:26:30 I msg:<***> Logger startup
2010-03-01 21:26:30 I msg:<***> version 0.2.0.0 build 0.0.7.0
2010-03-01 21:26:30 D msg:<***>
2010-03-01 21:26:30 I msg:[main] calculated cpu count is 2
2010-03-01 21:26:30 I msg:[main] starting 2 network threads
2010-03-01 21:26:30 I msg:[ban] Banned 0 IP's
2010-03-01 21:26:30 I msg:[rip] 0 entries in rip list

It has to be killed with "kill-9" ...

Regards, Klaus

[nitromix]

Originally posted by Klausi2007
Is it possible to relay a 1.9.8 server without yp2 compatibility?

When i try "relayport" and "relayserver", the sc_serv ends up there:

shoutcast2beta# ./sc_serv sc_10666.conf
2010-03-01 21:26:30 I msg:<***> Logger startup
2010-03-01 21:26:30 I msg:<***> version 0.2.0.0 build 0.0.7.0
2010-03-01 21:26:30 D msg:<***>
2010-03-01 21:26:30 I msg:[main] calculated cpu count is 2
2010-03-01 21:26:30 I msg:[main] starting 2 network threads
2010-03-01 21:26:30 I msg:[ban] Banned 0 IP's
2010-03-01 21:26:30 I msg:[rip] 0 entries in rip list

It has to be killed with "kill-9" ...

Regards, Klaus

From what i understnd from config files, for relay you have to use:
streamrelayurl=

Personal i try to get relay from SHOUTcast 1.9.8 but all the time on Winamp i get this error: "[ICY 401 Service Unavailable]]"

SHOUTcast 2 connect on SHOUTcast 1.9.8, get the stream signal and after that i get:

2010-03-01 23:42:27 E msg:[dst 192.168.1.89:4742 sid=2] Shoutcast 1 cl
ient connection rejected. Stream not available. WinampMPEG/5.57, Ultravox/2.1
2010-03-01 23:42:39 W msg:[yp2] Timeout waiting for data retrying
2010-03-01 23:42:39 I msg:[yp2] Connecting to yp.shoutcast.com

So without a clear info about config file and maybe a working YP2, we can not use yet

[Greg_E]

How about adding support for Flash encoders and Flash streaming?(kernel level not built on Java)

[bored_womble]

to get a relay working from a current Shoutcast server use the following

PHP Code:

portbase=8000
password=changeme
adminpassword=changeme
relayshoutcastdebug=1
relaydebug=1
log=1
yp2=1
publicserver=never
logfile=./test.log
streamid_1=5
streamauthhash_1=test
streampath_1=/test
streamrelayurl_1=http://<ip>:<port> 


Now lets assume your server ip is A.B.C.D

You can then pop into your Winamp player

http://A.B.C.D:8000/test

and it will play the stream from SC2.

BW

[Klausi2007]

Originally posted by bored_womble
to get a relay working from a current Shoutcast server use the following

PHP Code:

portbase=8000
password=changeme
adminpassword=changeme
relayshoutcastdebug=1
relaydebug=1
log=1
yp2=1
publicserver=never
logfile=./test.log
streamid_1=5
streamauthhash_1=test
streampath_1=/test
streamrelayurl_1=http://<ip>:<port> 


Now lets assume your server ip is A.B.C.D

You can then pop into your Winamp player

http://A.B.C.D:8000/test

and it will play the stream from SC2.

BW

Absolutely GREAT! This works. And it gives me a great pleasure, that it relays a NSV stream from a DNAS 1.9.8 with this little tricky config:

PHP Code:

streamid_1=5
streamauthhash_1=test
streampath_1=/test.nsv
streamrelayurl_1=http://<ip>:<port> 


If I point winamp to the 2.0 DNAS with the Link

PHP Code:

<serverip>:<port>/test.nsv 


it works. But I think, this is the "half official" way because if I klick the "listen" link on the 2.0 DNAS page for StreamID 5, it gives winamp

PHP Code:

http://<serverip>:<port>/test;stream.nsv 


which not works :-)

Regards, Klaus

[nradisch]

That looks correct. I didn't test the NSV stuff very carefully since Aol has pretty much abandonded it as a platform, so the URL generation code that shows up in the DNAS page is probably just buggy. I'll take a look at it.

--Neil

[Klausi2007]

Originally posted by nradisch
That looks correct. I didn't test the NSV stuff very carefully since Aol has pretty much abandonded it as a platform, so the URL generation code that shows up in the DNAS page is probably just buggy. I'll take a look at it.

--Neil

Beleave it or not - I know, I will be very experimental today - when you change nothing at the config code and the url generation code - Here is a correct functional way:

PHP Code:

streamid_1=5
streamauthhash_1=test
streampath_1=/test;stream.nsv
streamrelayurl_1=http://<ip>:<port> 


This gives the listen link on the 2.0 DNAS Page for StreamID 5 an absolutely correct listen link for the nsv :-)

When nothing will be changed - It only have to be documented

Let me also include many thanks for your great work on Shoutcast DNAS :-)

Regards, Klaus

[nradisch]

Awesome, so I didn't screw it up after all :-)

--Neil

[bored_womble]

my bug list so far

i) RelayServer and RelayPort really are foobared. Sc2 just stops, even strace fails.

ii) when relaying with the multiple stream option you can not use YP1 for listing, but I suspect this relates to (i)

iii) There is no llama link , surely something add

Any chance of the latest UVOX spec ? as I want to write a client withouth the need to transcode like SC_Trans2 does. I have used the one published but I know it is out of date.

BW

[jaromanda]

request for UVOX spec seconded

[nradisch]

bored_womble -

You cannot use YP1 for multistreams. The operational spec for YP1 does not provide the mechanism for making sensible entries in this case.

In YP1 every stream is defined by an IP address and a port only. This makes it impossible to define multiple streams of a single port using URL specifications. YP2 does not have this restrictions, and it's all related to our desire to break away from the requirement of having a separate sc_trans for every stream.

--Neil

[jaromanda]

a noticeable absence of response regarding the UVOX spec

[BornKillaz]

Hi.

I'm getting this on logs:

code:


2010-03-04 14:44:25     I       msg:<***>       Logger startup

2010-03-04 14:44:25     I       msg:<***>       version 0.2.0.0 build 0.0.7.0

2010-03-04 14:44:25     D       msg:<***>

2010-03-04 14:44:25     I       msg:[main] calculated cpu count is 2

2010-03-04 14:44:25     I       msg:[main] starting 2 network threads

2010-03-04 14:44:25     I       msg:[ban] Banned 0 IP's

2010-03-04 14:44:25     I       msg:[rip] 1 entry in rip list

2010-03-04 14:44:25     I       msg:[microServer]Listening for connection on port 8000

2010-03-04 14:44:25     I       msg:[microServer]Listening for connection on port 8001

2010-03-04 14:44:25     I       msg:[microServer]Listening for connection on port 8000

2010-03-04 14:44:25     E       msg:Error opening port 8000 because Could not bind to :8000 because Address already in use

2010-03-04 14:44:25     I       msg:[main] Terminating sources

2010-03-04 14:44:25     I       msg:[main] Waiting for final YP remsrvs

2010-03-04 14:44:25     I       msg:[main] Runner shutdown

2010-03-04 14:44:25     I       msg:<***>       Logger shutdown

I have nothing else running on port 8000

Can't start the sc_serv, what can I do??

I'm on CentOS 5.4

Also, why there is no sc_serv config sample file on this release?