ServIP=127.0.0.1 and icecast
ServIP=127.0.0.1 and icecast
hey Jay, can you tell I've been testing a lot lately?
This is only tested on freebsd so far, but when I set ServIP to 127.0.0.1, I can log in from a remote location using a shoutcast type login, but not a icecast2 type login. commenting out the ServIP results in it working. I do not see the failed connection attempt in the log.
Is this an unavoidable limitation of icecast type connections? Or something that can be addressed by you?
This is only tested on freebsd so far, but when I set ServIP to 127.0.0.1, I can log in from a remote location using a shoutcast type login, but not a icecast2 type login. commenting out the ServIP results in it working. I do not see the failed connection attempt in the log.
Is this an unavoidable limitation of icecast type connections? Or something that can be addressed by you?
the reason for setting it to localhost is precisely so it's unavailable for directly listening on the internet. it has a relay on the same server that is open to the internet that people can listen on.
the idea here is that there are two mounts hidden. call one a studio mount, and the other a dj mount. the idea is that a dj can connect, or the studio can connect. because dj is the backup mount for studio, when studio disconnects, the connection is piped to listen to the dj. this let's the studio override the dj. this setup works well, provided the connections on the localhost instance is a shoutcast type. it won't work when the studio connects via an icecast2 style connection. unfortunately, there is a limitation I have where the studio can only connect via an icecast2 protocol.
i guess I'm asking if icecast2 protocol makes more than one connection, or one that requires something that is currently made invisible on steamcast when it's set to localhost in ServIP. and more to point, is this something you're in a position to accommodate easily, or will it be something you can't, or never intend to address. (thinking long term here).
thanks jay.
the idea here is that there are two mounts hidden. call one a studio mount, and the other a dj mount. the idea is that a dj can connect, or the studio can connect. because dj is the backup mount for studio, when studio disconnects, the connection is piped to listen to the dj. this let's the studio override the dj. this setup works well, provided the connections on the localhost instance is a shoutcast type. it won't work when the studio connects via an icecast2 style connection. unfortunately, there is a limitation I have where the studio can only connect via an icecast2 protocol.
i guess I'm asking if icecast2 protocol makes more than one connection, or one that requires something that is currently made invisible on steamcast when it's set to localhost in ServIP. and more to point, is this something you're in a position to accommodate easily, or will it be something you can't, or never intend to address. (thinking long term here).
thanks jay.
- Jay
- Will work for food (Administrator)
- Posts: 3020
- Joined: Mon Jan 14, 2002 12:48 am
- Location: Next Door
- Contact:
the issue is that an icecast source connects to the serv port always rather then the src Port. It's a difference between the two protocals, the description of srcIP in the config is a bit more tied to the shoutcast specification. Under Icecast2 there is no seperate src port. Under your configuration your Icecast source would need to be on the localhost to work.
- Jay
- Jay
- Will work for food (Administrator)
- Posts: 3020
- Joined: Mon Jan 14, 2002 12:48 am
- Location: Next Door
- Contact:
I will also look into the possibility of accepting icecast source's on the src port, this would require that you use the src port in the icecast sourcing tool instead. I can't guarantee this one to happen soon because it may require more work then I wish to add at this time but I will guarantee that it will be added at some point.
- Jay