Old 21st November 2011, 13:23   #1
djmasa
Junior Member
 
Join Date: Jan 2005
Location: Denver, Colorado
Posts: 29
Send a message via AIM to djmasa Send a message via Yahoo to djmasa
Found a possible bug with SC2.

Hey all,

So decided to do this without much forethought and found myself in a bad situation. I got everything working with SC2 in Legacy v1 the way I want except for I noticed a little problem.

If riponly or streamriponly is setup on a legacy v1 setup, it denies access to the web administration site. it says the IP isn't in the reserve IP list, but it is, and, additionally, Winamp can connect to it and get the stream. So is this a bug?

I can turn on RIPONLY and works as intended for the streams, but denies web connections, even though the IP is present, so I have no access to the web interface until this problem is solved. Is there another option I've missed somewhere? I've tried both the riponly and streamriponly options, and the result is the same.

Thanks for any help you can provide.

--
masa,
Japan-A-Radio; Japan's best music mix!
http://www.japanaradio.com/
djmasa is offline   Reply With Quote
Old 21st November 2011, 13:27   #2
DrO
 
Join Date: Sep 2003
Posts: 27,873
i might already have fixed that quirk for the next v2 DNAS release but will have to double-check and let you know / try out a test build to see if all works ok.

-daz
DrO is offline   Reply With Quote
Old 21st November 2011, 14:20   #3
djmasa
Junior Member
 
Join Date: Jan 2005
Location: Denver, Colorado
Posts: 29
Send a message via AIM to djmasa Send a message via Yahoo to djmasa
Okay. I'll be happy to test that out for you. I use a bit more of a secure network using that feature than most people.

What's the suggested config when not using the transcoder to do a relay setup for a legacy v1 setup? Apparently, I'm having trouble getting it to work.

Thanks.

--
masa,
Japan-A-Radio; Japan's best music mix!
http://www.japanaradio.com/
djmasa is offline   Reply With Quote
Old 21st November 2011, 14:39   #4
DrO
 
Join Date: Sep 2003
Posts: 27,873
will need to know what platform version of the DNAS you're using (so i can sort out an appropriate test build).

with the relaying question, either streamrelayurl or relayserver + relayport can be used to specify it. though there are some 'quirks' with what's allowed (e.g. handling of http:// on the url or it not being always recognised as a stream configuration) with the public build so the test build will be better to work against trying it out.

-daz
DrO is offline   Reply With Quote
Old 21st November 2011, 14:44   #5
djmasa
Junior Member
 
Join Date: Jan 2005
Location: Denver, Colorado
Posts: 29
Send a message via AIM to djmasa Send a message via Yahoo to djmasa
I'm using FreeBSD 8.x build. And I'm finding relays not working at all no matter what i've tried. it's like it doesn't even try to contact the relay server when the data is in:
I've tried:

relayport=10000
relayserver=http://serverhostname:10000/

i've also tried the above with the port, and with relayserver just being the serverhostname

I've also tried:
streamid=1
streamrelayurl=http://serverhostname:10000/stream/1/
as well as
streamrelayurl=http://serverhostname:10000/

and

streamrelayurl_1=http://serverhostname:10000/stream/1/

and

streamrelayurl_1=http://serverhostname:10000/

can't seem to get anything to work. and with DNAS 1.9.8 not working at all on 8.x, i'm a little stuck.

--
masa,
Japan-A-Radio; Japan's best music mix!
http://www.japanaradio.com/
djmasa is offline   Reply With Quote
Old 21st November 2011, 14:56   #6
DrO
 
Join Date: Sep 2003
Posts: 27,873
for the relayserver+relayport method (which is what the v1 DNAS used) it should be
Quote:
relayport=10000
relayserver=serverhostname
though if things are failing then there should be some sort of message in the log.

though as mentioned in my prior reply, there are some issues with relay settings being processed with the public build so it'll be simpler for debugging, etc against the test build which has a slew of fixes for such things in place.

-daz
DrO is offline   Reply With Quote
Old 21st November 2011, 14:59   #7
djmasa
Junior Member
 
Join Date: Jan 2005
Location: Denver, Colorado
Posts: 29
Send a message via AIM to djmasa Send a message via Yahoo to djmasa
yeah, i've been looking at the debugs for the relay servers and what not via the log file, and haven't seen anything. I turned on all the debugs just to verify, but one server has so much chatter with people trying to connect, it makes it impossible to be able to follow, so i limited it to source and relay options and turned off client logging for now. The relay server and the server it's relaying from both have debugging turned on, and that's why I said it seems like it doesn't do anything, because there is no log entries either way. I'll try it again.


Thanks.

--
masa,
Japan-A-Radio; Japan's best music mix!
http://www.japanaradio.com/
djmasa is offline   Reply With Quote
Old 21st November 2011, 18:23   #8
DrO
 
Join Date: Sep 2003
Posts: 27,873
pm sent with a link to a BSD test build to try out. have changed things so that if riponly is set, connecting from 127.0.0.1 will always be allowed through for the admin pages.

-daz
DrO is offline   Reply With Quote
Old 22nd November 2011, 08:02   #9
djmasa
Junior Member
 
Join Date: Jan 2005
Location: Denver, Colorado
Posts: 29
Send a message via AIM to djmasa Send a message via Yahoo to djmasa
Early Reports

Thanks, DrO. I got the test version you sent. I've so far tested the relay and it appears to work. I noticed that when using a relay, it forces me to use yp2 mode, even though i selected legacy mode. I also noticed that if the publicserver=default (or always) and it doesn't make a connection to the YP, it doesn't allow any clients to listen. That raises a concern, because if for some reason the yp becomes unavailable, direct listens won't work. Is that something that can be worked around? Apparently, I need setup an authhash for our station, but I haven't done it yet. I still need to test the riponly / streamriponly issue. I'll follow up in a bit on that.

Thanks for all your help.

--
masa,
Japan-A-Radio; Japan's best music mix!
http://www.japanaradio.com/
djmasa is offline   Reply With Quote
Old 22nd November 2011, 10:15   #10
DrO
 
Join Date: Sep 2003
Posts: 27,873
Quote:
Originally Posted by djmasa View Post
I've so far tested the relay and it appears to work.
Quote:
Originally Posted by djmasa View Post
I noticed that when using a relay, it forces me to use yp2 mode, even though i selected legacy mode.
that shouldn't be happening, would need to re-check that.

Quote:
Originally Posted by djmasa View Post
I also noticed that if the publicserver=default (or always) and it doesn't make a connection to the YP, it doesn't allow any clients to listen. That raises a concern, because if for some reason the yp becomes unavailable, direct listens won't work. Is that something that can be worked around?
when the DNAS is working in YP2 mode, if the details from the authhash cannot be obtained from the YP then it will prevent clients since the stationname, etc passed to the clients is taken from the authhash details (unlike the v1 system which just uses what the source provides - in yp1 mode then that will still happen). as such clients aren't allowed since the DNAS is then in an illegal state. it probably seems counterintuitive but that's how it's been setup and will remain as things stand.

Quote:
Originally Posted by djmasa View Post
Apparently, I need setup an authhash for our station, but I haven't done it yet.
that's easily done, you just need to go in via the 'server login' and then follow the create authhash option from there for the stream.

Quote:
Originally Posted by djmasa View Post
I still need to test the riponly / streamriponly issue.
will be good to know if that's resolved as well for you.

-daz
DrO is offline   Reply With Quote
Old 22nd November 2011, 12:28   #11
djmasa
Junior Member
 
Join Date: Jan 2005
Location: Denver, Colorado
Posts: 29
Send a message via AIM to djmasa Send a message via Yahoo to djmasa
I checked it out.

The relays are forcing yp2 mode. If you specify a relayport and relayserver, it acts like you've specified streamrelayurl and says that yp2 must be turned on.


So far, I've checked the RIP system, and I think that's working now as intended.

Well, I see that yp2 issue as a problem if the YP ever goes down for an extended period of time or AOL/Nullsoft decides to stop supporting the service entirely. That would be pretty unfortunate either way for the stations. Not sure how I want to deal with that for now.

--
masa,
Japan-A-Radio; Japan's best music mix!
http://www.japanaradio.com/
djmasa is offline   Reply With Quote
Old 22nd November 2011, 12:55   #12
DrO
 
Join Date: Sep 2003
Posts: 27,873
Quote:
Originally Posted by djmasa View Post
The relays are forcing yp2 mode. If you specify a relayport and relayserver, it acts like you've specified streamrelayurl and says that yp2 must be turned on.
it's because i re-map the legacy options to the new one - not a simple change to get that altered though as yp2 mode is the default behaviour it's not going to be as high up on my todo list for the moment.

Quote:
Originally Posted by djmasa View Post
So far, I've checked the RIP system, and I think that's working now as intended.
that's good.

Quote:
Originally Posted by djmasa View Post
Well, I see that yp2 issue as a problem if the YP ever goes down for an extended period of time or AOL/Nullsoft decides to stop supporting the service entirely. That would be pretty unfortunate either way for the stations. Not sure how I want to deal with that for now.
i can see why you're concerned though there's no intention on stopping support of the YP / site listings.

if it did go down then switching the DNAS to run in private mode would be the simplest way around it (though at the moment the v2 DNAS doesn't allow for changing that on the fly in all cases). then again, the service going away would affect v1 stations in a similar manner, so i think you might be over considering things (though can see why).

though as the yp2 mode works with the stored authhash details then i'd hope it makes sense why if the details cannot be obtained that the DNAS probably shouldn't be running as no details &/or no YP connection when set to be public is an invalid setup. at least it won't drop listeners if the YP connection goes away whilst the DNAS is running unlike the v1 DNAS can do.

-daz
DrO is offline   Reply With Quote
Old 23rd November 2011, 00:36   #13
DrO
 
Join Date: Sep 2003
Posts: 27,873
Quote:
Originally Posted by djmasa View Post
The relays are forcing yp2 mode. If you specify a relayport and relayserver, it acts like you've specified streamrelayurl and says that yp2 must be turned on.
luckily (or not) i cannot sleep so i've worked through and fixed the handling for the above issue - pm sent with link to a newer test build to try.

-daz
DrO is offline   Reply With Quote
Old 28th November 2011, 13:01   #14
DrO
 
Join Date: Sep 2003
Posts: 27,873
had wondered if holidays were involved well that's good that it's working better than the v1 from your tests so far.

what issues are you seeing as i've tried to ensure the xml output matches the v1 output where applicable (though i'm not too sure what SpacialAudio's SOS product is / was). also if you've set a streampath for stream#1 then you may need to disable that in the config file so that any tool / client access will be more like how the v1 DNAS accepted such requests (the public build defaulted the path to /stream/1/ whereas the test build you've got is just using / if streampath is not specified).

-daz
DrO is offline   Reply With Quote
Old 9th December 2011, 08:31   #15
djmasa
Junior Member
 
Join Date: Jan 2005
Location: Denver, Colorado
Posts: 29
Send a message via AIM to djmasa Send a message via Yahoo to djmasa
Sorry that it's been a week or so. Been really busy. Lots of station imaging and stuff to do this time of year.

Anyway, the errors that SOS present for the XML are:

Error parsing xml document: End tag 'head' does not match the start tag 'link'.

I also believe it may use some of the 7.html stuff from v1.

Because you may or may not now, SOS is basically an older version of SimpleCast (Now called SAMCast) that includes ad-insertion and blackout features not present in SimpleCast or SAMCast. You can probably find out more from SpacialAudio's Wiki, if you wish to know more about it. It's basically using the SHOUTcast v1 relay statistics found in SimpleCast and SAMcast, which do not seem to be compatible with SHOUTcast v2 even in legacy mode with the error listed above. There is no log file for the statistics portion of SOS.

Please let me know if you need anymore information. I'll try to get you what I can.

--
masa,
Japan-A-Radio; Japan's best music mix!
http://www.japanaradio.com/
djmasa is offline   Reply With Quote
Old 9th December 2011, 08:48   #16
djmasa
Junior Member
 
Join Date: Jan 2005
Location: Denver, Colorado
Posts: 29
Send a message via AIM to djmasa Send a message via Yahoo to djmasa
Just also as a follow-up, the changes that you made for the RIP of the webinterface seem to not be working again. I can't access the webserver portion of the server even if I am in the RIP list and the server is set for RIP only. Not sure how that happens. I put this on a more busy server stream to see how it's functioning, and other than the RIP/WEB issue, along with XML issue of the previous post, it seems to be okay.

--
masa,
Japan-A-Radio; Japan's best music mix!
http://www.japanaradio.com/
djmasa is offline   Reply With Quote
Old 9th December 2011, 11:08   #17
DrO
 
Join Date: Sep 2003
Posts: 27,873
Quote:
Originally Posted by djmasa View Post
Sorry that it's been a week or so. Been really busy. Lots of station imaging and stuff to do this time of year.
that's ok, can understand that

Quote:
Originally Posted by djmasa View Post
Anyway, the errors that SOS present for the XML are:

Error parsing xml document: End tag 'head' does not match the start tag 'link'.

I also believe it may use some of the 7.html stuff from v1.
ok, there's not too much that can be done about that if it is hitting 7.html since that is 404'd with the build i sent to you as we moved things over to an xml /stats option for the v2 DNAS (7.html wasn't deemed appropriate anymore and was removed - was done before i took on the tools). as such there's not anything which can be changed on that handling (not what you're wanting to hear but that's what has been decided).

Quote:
Originally Posted by djmasa View Post
Just also as a follow-up, the changes that you made for the RIP of the webinterface seem to not be working again. I can't access the webserver portion of the server even if I am in the RIP list and the server is set for RIP only. Not sure how that happens. I put this on a more busy server stream to see how it's functioning, and other than the RIP/WEB issue, along with XML issue of the previous post, it seems to be okay.
the 'fix' i put in only works when accessing the admin pages on the same machine and the DNAS determines the request is made from 'localhost'. to work on the remote machine you'd need to add your IP to the rip file though i think i need to re-evaluate the handling of the page access when RIP is in use so any valid admin login is allowed.

-daz
DrO is offline   Reply With Quote
Reply
Go Back   Winamp & Shoutcast Forums > Shoutcast > Shoutcast Technical Support

Tags
admin interface, relay, riponly, sc2, streamriponly

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump