q & requst
q & requst
Hi,
why sc style url like http://localhost:9000/;bla.nsv not allowed?
i mean with ";" thing. i don't like idea changing linking urls due server change.
any possibilities of adding users limits by ip subnets something like
net1=192.168.0.0/16
users1=123
net2=193.219.128.0/12
users2=12
net3=0.0.0.0/0
users3=1
well something in that style, or maybe there is sc server supporting this
why sc style url like http://localhost:9000/;bla.nsv not allowed?
i mean with ";" thing. i don't like idea changing linking urls due server change.
any possibilities of adding users limits by ip subnets something like
net1=192.168.0.0/16
users1=123
net2=193.219.128.0/12
users2=12
net3=0.0.0.0/0
users3=1
well something in that style, or maybe there is sc server supporting this
blah forever
- Jay
- Will work for food (Administrator)
- Posts: 3022
- Joined: Mon Jan 14, 2002 12:48 am
- Location: Next Door
- Contact:
Re: q & requst
That should work, at least it worked when I tested it, if you could pm me a link to your server and i'll check it out. Otherwise listing in the Internet TV listing wouldn't work. One thing, be sure that you are testing the url in Winamp, Browsers will get 404's.slavas wrote:Hi,
why sc style url like http://localhost:9000/;bla.nsv not allowed?
i mean with ";" thing. i don't like idea changing linking urls due server change.
Yea, I have thought about such a feature because it would be great to have user maxes more relative to the interface or network they are on. I.E. having LAN gives a lot more bandwidth then the WAN so why not allow more users who connect through it.slavas wrote:any possibilities of adding users limits by ip subnets something like
net1=192.168.0.0/16
users1=123
net2=193.219.128.0/12
users2=12
net3=0.0.0.0/0
users3=1
well something in that style, or maybe there is sc server supporting this
All possible. May take me little time to work out the code for it.
- Jay
Hi, my server is on lan :/, but i mean
SourceMount=/;stream.nsv
and server complaining:
[10/05/2004@01:17:04] Configuration Error: Definition of / or /;* as SourceMount
s are illegal, use SourceDefault instead
maybe i misunderstood something configuring it?
btw isn't my sourcer compliant if it at first updates title and then (immediately) starts sending data? in such scenario Your server likes to crash...
SourceMount=/;stream.nsv
and server complaining:
[10/05/2004@01:17:04] Configuration Error: Definition of / or /;* as SourceMount
s are illegal, use SourceDefault instead
maybe i misunderstood something configuring it?
btw isn't my sourcer compliant if it at first updates title and then (immediately) starts sending data? in such scenario Your server likes to crash...
blah forever
- Jay
- Will work for food (Administrator)
- Posts: 3022
- Joined: Mon Jan 14, 2002 12:48 am
- Location: Next Door
- Contact:
yea because /;* is assumed to be /
so just set SourceMount=/something.nsv
and set SourceIsDefault=Yes
This will allow your stream to be found at /something.nsv
/
and
/;*
and the old sc way of /;anything.nsv will work
The reason that you cannot specify it is due to SHOUTcast YP directory compliance.
As far as your source updating titles before initiating a source that's an undefined area, however, it should not crash I will fix that in my 0.9.6 build. The reason it probably crashes is due to the source thread not being created. Unlike SHOUTcast my server builds threads as it needs them. This model is neccessary for multiple mounts which SHOUTcast does not support so shoutcast's source thread always exists. Given that is the way it works it would be safer for your source app to send title information only after a source connection has initiated. With the way you implement it, you don't even know if you have rights to the server until you have attached your encoder so it's kind of pointless to send the meta data first if the person is using the wrong password.
[Edit]BTW here is how my source apps handle this handshake.
-> Source Connect (send password)
<- Bad password or OK2
-> Throw Headers
-> Send meta title
-> Send Data
This is the safest model I have found and tends to work with just about any implementation of the SC system I have come across.
so just set SourceMount=/something.nsv
and set SourceIsDefault=Yes
This will allow your stream to be found at /something.nsv
/
and
/;*
and the old sc way of /;anything.nsv will work
The reason that you cannot specify it is due to SHOUTcast YP directory compliance.
As far as your source updating titles before initiating a source that's an undefined area, however, it should not crash I will fix that in my 0.9.6 build. The reason it probably crashes is due to the source thread not being created. Unlike SHOUTcast my server builds threads as it needs them. This model is neccessary for multiple mounts which SHOUTcast does not support so shoutcast's source thread always exists. Given that is the way it works it would be safer for your source app to send title information only after a source connection has initiated. With the way you implement it, you don't even know if you have rights to the server until you have attached your encoder so it's kind of pointless to send the meta data first if the person is using the wrong password.
[Edit]BTW here is how my source apps handle this handshake.
-> Source Connect (send password)
<- Bad password or OK2
-> Throw Headers
-> Send meta title
-> Send Data
This is the safest model I have found and tends to work with just about any implementation of the SC system I have come across.
- Jay