Icecast Streaming Media Server

[kewlkeed]

Hello again,

I didn't want to hijack my last thread with this question.

What I want to know is if it is possible to have icecast act the same as a shoutcast server for my client's perspective.

Reason I ask is I am running a multiple instance Shoutcast server that I want to replace with Icecast because it seems better on resources...

HOWEVER, my problem is that I have 40+ instances/clients. I don't want to have to contact each client and tell them they need to change their source connections and listener connections to different settings.

The only problem I see is the mountpoints. Is there any way I can do this without having to ask the sources/listeners to add the /mountpoint to their addresses?

This way they can continue to just stream to
xxx.xxx.xxx.xxx:8000
and listen to
http://xxx.xxx.xxx.xxx:8000

I don't want to add in "/stream" or mount points to the address if it is possible.

Also something that I don't see as clear yet for Shoutcast, the port and port+1.

I am used to setting the source and listen ports to the same port. Is this still going to stay the same for icecast (Even though I specify two ports in the config?) I know Shoutcast will use 8000 and 8001... However nobody ever has to specify the 8001, it just knows to +1 automatically. So I just need to give one port number out.

So I guess my questions are

1) Do I need to use mountpoints? Or can I just keep it simple and the same as my current system

2) Can I have source and listeners on the same port (Or at least where I only specify the same port to them to use)

[karlH]

1. mountpoints also exist, just look at what exactly the players request, they request / for shoutcast. icecast can also use a mountpoint of / if you really want it to.

2. icecast sources only use one port, shoutcast sources often use 2 ports per stream. shoutcast sources send mainly on port+1 which listeners cannot use. So no you cannot have them both on the same port in that case but you can if the source is a native icecast source.

You need to understand that each of those 40 streams need a unique way for being identified. If they are are all on separate instances of the process (uniquely addressed by IP/port) then the mountpoints can be / (icecast is able to handle that). 80 ports would be needed for shoutcast source clients.

If you want a single icecast to handle all 40 streams then each stream needs a unique mountpoint. With shoutcast source clients, 40 listen-sockets blocks each with a shoutcast-mount would work. There's no Host header sent with shoutcast source clients so the IP/port has to determine the mapping. Using the 40 shoutcast-mount settings along with the alias of / to /mountpoint based on port for listeners,

karl.



karl.

[DJ-Zath]

a side question based on "multiple shoutcast streams" per Icecast session..

I could NOT get more than ONE shoutcast mount to work per session in icecast- even if I used seperate port assignments..

my understanding is that Icecast assigns "/source" to any shoutcast-configured mount.. and I have been unable to re-assign this.. so it "breaks" things if I attempt more than one shoutcast source... (one shoutcast source and x-number of icecast sources works fine!)

I gotta ask, is it possable to have more than one shoutcast source amongst icecast sources on the same instance?

from what I'm reading here, the answer is "no" since icecast doesn't assign the x+1 port to anything EXCEPT "/source" when its called up..

this means if I want to run shoutcast mounts, I have to use a seperate Icecast instance- then relay them one-to-the-other.. how MESSY!

-DjZ-

[karlH]

the assumption you are making about the mountpoint is incorrect. A shoutcast-mount within a listen-socket block not only implicitly defines the port+1 port ready for use but also specifies the mountpoint to use when shoutcast source client connects.

so
<listen-socket>
<port>8000</port>
<shoutcast-mount>/somestream</shoutcast-mount>
<listen-socket>

<listen-socket>
<port>9000</port>
<shoutcast-mount>/someotherstream</shoutcast-mount>
<listen-socket>

will listen on ports 8000,8001,9000 and 9001 using 2 different mountpoints.

karl.

[DJ-Zath]

oh? I have tried that.. but, tell you what.. I'll try it again (maybe I missed something)

I sure hope this works!

(okay then how does one assign the password for the second SC mount??)

<authentication>
<source-password>hackme<source-password>
</authentication>

I found changing "source-password" to "sourece2-password" didn't work

again, I will try all this and see if I can get it working...

thanks Karl!

-DjZ-

[karlH]

if you don't want to use a global source password then use a per <mount> password. In the case of a shoutcast source connection, there is no username to match.

karl.

[DJ-Zath]

UPDATE:

okay I have placed the shoutcast mount assignment into a listen block..

<port>8000</port>
<bind-address>64.6.9.129</bind-address>
<shoutcast-compat>1</shoutcast-compat>
<shoutcast-mount>/input</shoutcast-mount>
</listen-socket>

and tried setting password as follows:

<authentication>
<input-password>HackMe</input-password>
</authentication>

and nothing works...

However, setting:

<authentication>
<source-password>HackMe</source-password>
</authentication>

works.. but I can't seem to set any OTHER mount except source

therefore, as I concluded before, I can't set any more tha one SC mount and its "defaults"as "source" and I can't figure out HOW to change it..

-DjZ-

[karlH]

If you look at what I wrote you will see that there is no shoutcast-compat setting specified in either of those 2 listen blocks.

When I wrote "a per-<mount> password" I mean literally

<mount>
<mount-name>/input</mount-name>
<password>anotherpassword</password>
</mount>


Just like you would do for an icecast source client.

karl.

[DJ-Zath]

okay!

I think I'm getting somewhere...

I set some <mount> tags for the shoutcast mounts..

I was hoping for them to share the same port(s) but I see that doesn't work.. gonna try setting up another port and popping a hole in the firewall for the new port(s)

again, thanks for the guidence! (sometimes the docs just aren't that easy to understand...)

(actually, I figured this out BEFORE I saw your latest entry.. we are thinking on the same lines, it seems not nessessarily a bad thing...)

-DjZ-

[DJ-Zath]

Thanks karl!

I got it working now...

The trick was to set a relay mount to localhost- so I can combine the shoutcast mounts to the same port (otherwise I'd have to recompile my downloadable players).

Though, and now this may eliminate the "workaround" I had to do to prevent the global SC stream from migrating across the mounts... (when the output stream ends up on the input mount, for example.. the studio experiences a nice juicy FEEDBACK LOOP!) clever use of aliases and setting a relay mount to "bind" the input mount to a fixed mount assignment is what I had to do to prevent this.. this was the case in 2.3.1 but I wonder, now, if 2.3.2 has fixed this interesting delimnea.. since I am able to set multiple sc mounts, thanks to your help, maybe I can eliminate the secondary 'relay" mounts...

-DjZ