Found a possible bug with SC2.

[djmasa]

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.

[DrO]

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

[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.

[DrO]

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

[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.

[DrO]

for the relayserver+relayport method (which is what the v1 DNAS used) it should be

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

[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.

[DrO]

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

[djmasa]

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.

[DrO]

Originally Posted by djmasa

I've so far tested the relay and it appears to work.

Originally Posted by djmasa

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.

Originally Posted by djmasa

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.

Originally Posted by djmasa

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.

Originally Posted by djmasa

I still need to test the riponly / streamriponly issue.

will be good to know if that's resolved as well for you.

-daz

[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.

[DrO]

Originally Posted by djmasa

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.

Originally Posted by djmasa

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

that's good.

Originally Posted by djmasa

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

[mystica555]

This thread has me interested in exactly how YP2/sc_serv2 actually work in comparison to v1 with regard to end-to-end reliability of a stream broadcast using v2 of the platform.

Originally Posted by DrO

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.

Originally Posted by DrO

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.

I would like more clarification on the implications of this setup.

Does this imply that if the YP2 directory connection cannot be made in the middle of an ongoing streaming session, then all clients who might try to connect after the YP2 link goes down will be denied while the connected listeners still remain engaged with the DNAS as if nothing happened?

Does this also imply that the YP2 is queried upon every client login and forwards the stream details at this time, furthermore implying that such stream information is not cached within sc_serv2 during its runtime?

Originally Posted by DrO

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).

You sound confused with regard to V1. Exactly how would losing the YP be the same for a V1 vs a V2 DNAS when the V2 DNAS is intrinsically different?

With V1, all I can figure is that there would be no public YP directory listing for the stream.

This lack of YP services does not preclude a stored URL in a playlist, nor a direct link from a website. V2 denies client connections if the back-end link to the YP is severed.

V1 streams remain connectible regardless of YP interaction.

Clients provided with direct links or with stored playlists always have the URL to the stream, and should at any moment be able to connect as they already know where the stream is. There is -no- requirement that clients visit the Shoutcast.com YP to access the stream in any case, thus there should be no denial for clients with a direct link in ANY situation. Why does V2 have this as a designed-in bug?

Is Nullsoft able to guarantee they will never go down, thus wrongfully denying radio listeners their stream due to a bad design of the DNAS? If the stream was working, and your ISP's core router fails at an inopportune moment, why should I have to change my configuration to fix your problem?

Please explain this. I am very curious. Seriously.

With the amount of potential for your failure to become my failure, why exactly would use such risky software? The only answer possible: Your market share locks customers in. There is no alternative directory that is in the mind of the masses. Your trademark has become a noun. You are the Kleenex of streaming media.

Due to this, why not make the software guaranteed reliable so as to not potentially damage the reputation of stations who wish to be publicised?

[DrO]

Originally Posted by mystica555

Does this imply that if the YP2 directory connection cannot be made in the middle of an ongoing streaming session, then all clients who might try to connect after the YP2 link goes down will be denied while the connected listeners still remain engaged with the DNAS as if nothing happened?

when using the v2 DNAS in YP2 mode, if the YP connection fails i.e. no touches then it will not prevent client connections. my comment is that the v1 DNAS under such situations can and does drop client connections - the v2 DNAS does not.

Originally Posted by mystica555

Does this also imply that the YP2 is queried upon every client login and forwards the stream details at this time, furthermore implying that such stream information is not cached within sc_serv2 during its runtime?

it's obtained when the v2 DNAS does it's add for the stream, otherwise as long as the source does not disconnect then the details obtained from the add will be used. i'm not sure how you got the idea that it's querying the YP for every client connection.

Originally Posted by mystica555

You sound confused with regard to V1. Exactly how would losing the YP be the same for a V1 vs a V2 DNAS when the V2 DNAS is intrinsically different?

With V1, all I can figure is that there would be no public YP directory listing for the stream.

Originally Posted by mystica555

This lack of YP services does not preclude a stored URL in a playlist, nor a direct link from a website. V2 denies client connections if the back-end link to the YP is severed.

no, as already covered it only prevents client connections if the add is not able to be made. as long as the add happens and things then fail after that then it won't affect things. however, see my last paragraph in this reply for a followup on this.

Originally Posted by mystica555

Clients provided with direct links or with stored playlists always have the URL to the stream, and should at any moment be able to connect as they already know where the stream is. There is -no- requirement that clients visit the Shoutcast.com YP to access the stream in any case, thus there should be no denial for clients with a direct link in ANY situation. Why does V2 have this as a designed-in bug?

there is no requirement that clients visit the site with the v2 DNAS either. if you're telling it to be listed in the YP then it's only fair that the DNAS favours that handling. why this was done i don't know (before my time working on the tools) but it seems fair how it works. and other people have raised the issue but if it's that much of a concern, you either revert it to work in YP1 mode or stick with your unsupported v1 DNAS.

Originally Posted by mystica555

Is Nullsoft able to guarantee they will never go down, thus wrongfully denying radio listeners their stream due to a bad design of the DNAS? If the stream was working, and your ISP's core router fails at an inopportune moment, why should I have to change my configuration to fix your problem?

no one can guarantee 100% uptime (and if they do then they are lying). as you seem to have mis-interpreted some of what i was trying to say, i think the above reaction is possibly going ott.

Originally Posted by mystica555

With the amount of potential for your failure to become my failure, why exactly would use such risky software? The only answer possible: Your market share locks customers in. There is no alternative directory that is in the mind of the masses. Your trademark has become a noun. You are the Kleenex of streaming media.

if you don't like the terms of using the tools then you don't have to use them. the choice is there. all i'm doing is working within the design which has been put in place before i started working on the tools and i can see that this will put some people off, but i can also see the benefits of using the authhash system (protects station details especially against rogue DJ's screwing with things, makes clustering easier by just ensuring the same authhash is used, has more aspects coming).

Originally Posted by mystica555

Due to this, why not make the software guaranteed reliable so as to not potentially damage the reputation of stations who wish to be publicised?

as already mentioned, no one can guarantee things to be 100% reliable be it software, networking, etc though it is strived to be achieved.


i'm not going to cover it as a bug, however more as a feature request since it is a fair point that if the YP cannot be accessed only if it fails to resolve / respond on add and not a failure to provide the information (that behaviour will not change), then yes it probably should drop the requirement to block client connections due to a lack of authhash details. however we then get into the weird area as to what to do to clients which have then be provided with different details from what would be in the authhash when the YP connection then comes back... kick all so they then get the correct details or just leave them going and only apply the new details to new connections.

so does that seem fair / alleviate the core issues you're having with how things currently are designed and work as planned?

-daz

[DrO]

Originally Posted by djmasa

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]

Originally Posted by DrO

i'm not going to cover it as a bug, however more as a feature request since it is a fair point that if the YP cannot be accessed only if it fails to resolve / respond on add and not a failure to provide the information (that behaviour will not change), then yes it probably should drop the requirement to block client connections due to a lack of authhash details.

as a follow up, i've now added in handling which should allow this to work so if the YP is not there / responding correctly i.e. its 404'ing due to some failure, it will allow clients through.

Originally Posted by DrO

however we then get into the weird area as to what to do to clients which have then be provided with different details from what would be in the authhash when the YP connection then comes back... kick all so they then get the correct details or just leave them going and only apply the new details to new connections.

with this part of what i mentioned, when YP connectivity comes back then it'll leave all existing clients connected and will then process new client connections according to the existing YP connection behaviour i.e. if your authhash is then invalid / does not exist then it'll reject client connections. that seems the best option if there are other issues which are in effect.

however, hopefully this shouldn't need to be tested (though the only likely time would be when we do YP upgrades and a coincidental timing of when the DNAS is started up.

-daz

[djmasa]

Sorry, I have been away for the holidays and was not able to fully take a look at it. The updated test daemon you sent seems to be working correctly for relays now as well. I've done a bit of testing with it, i'll switch one major relay over and see how well it handles the load. If it's acceptable, I'll move them all over and retire 1.9.8 which seems to be sucking CPU like no tomorrow due to what i'm sure is a very low sleep setting. I have a few more issues to work out, since SpacialAudio seems to no longer produce SOS, my SHOUTcast server listener data can no longer be tracked due to the differences on how v1 and v2 operate their XML code. I may have to work around that somehow, but we'll see. It's not a huge problem as of yet, just a minor annoyance, and I doubt there's anything you can do in code to fix it unless v1 legacy mode can also operate the XML in the same manner (but I doubt it).

[DrO]

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

[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.

[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.

[DrO]

Originally Posted by 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.

that's ok, can understand that

Originally Posted by djmasa

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).

Originally Posted by 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.

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