Jump to content

DJ Board Display Not Working Properly


Glad Gaffer
 Share

You are about to reply to a thread that has been inactive for 1505 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

On 6/29/2017 at 9:14 AM, Shuichi Shinji said:

And another question: Would it be possible to parse the hack (in a very restrictive way to avoid security issues) and build a standard-conforming HTTP request out of it? That would have the advantage that old scripts incl. SHX would still work. The preferred way would of course be the one using the extra options for user agent and potentially to skip the default headers, but to not break old content, the hack parsing would really be helpful...

It's our judgement that this wouldn't be a good idea. We think we've made changes that should allow updated scripts to work with most servers (see yesterdays post)

Link to comment
Share on other sites

Any news on this? I'm living on Mainland and thus on the main server release (i think). Tested my own board script on a magnum region today and still get a 403 reply from the shoutcast servers.

I replaced the old code:

fetch() { HTTPRequest=llHTTPRequest         (URL + "/7.html HTTP/1.0\nUser-Agent: LSL Script (Mozilla Compatible)\n\n",[],""); }

with this new:

fetch() {HTTPRequest=llHTTPRequest(URL + "/7.html",[HTTP_USER_AGENT, "Stream-Script/1.0 (Mozilla Compatible)"],"");}

I still get a 403 response from the shoutcast servers (this test was run with the http://bigdaddys.digistream.info:20368 stream). Funny thing i did notice is that apparently the old code do pull the meta data from shoutcast v1.x, but not from the newer v2.x - which Big Daddys are running.

Stream Info Board V1.8a: d82154a4-0e7c-b1c7-8205-e3589d959bff, d82154a4-0e7c-b1c7-8205-e3589d959bff, 403,

Edited by Linnrenate Crosby
Link to comment
Share on other sites

@Linnrenate Crosby Later changes are available for testing on the Beta-grid.  See Oz Linden post 2:17 pm Thursday part of which said:

"Go to any of Leafeon, Sylveon, Umbreon and Glaceon on Aditi, or you can look for server version 17.06.28.327400 on http://aditi.coreqa.net/gridtool.php (we'll be adding some more regions shortly).

If you've never used the Beta grid, see http://wiki.secondlife.com/wiki/Aditi#How_do_I_log_in_to_Aditi.3F "

Link to comment
Share on other sites

ok seems the issue on with the statistics relay at the RC Magnum regions remain the same problem and get error.....

but i was on sl beta at a region: DRTSIM-323  17.06.29.327400 and did some few tests with this new HTTP_USER_AGENT code and seems is working fine :D:

Status:200, ResponseBody:<HTML><meta http-equiv="Pragma" content="no-cache"></head><body>7,1,23,1000,7,128,Alien Vampires - Humans=Cunts</body></html>

but i still got error on some few streamers like: http://sl_live_radio.net-radio.org:8167 - SL Live Radio : "URL passed to llHTTPRequest is not valid"

is this good news?

do we have to wait for further information about updates on sl servers? because that HTTP_USER_AGENT is still not valid on sl?

thanks in advance

statistics relay.png

Edited by Daffy Proto
Link to comment
Share on other sites

10 hours ago, Daffy Proto said:

but i was on sl beta at a region: DRTSIM-323  17.06.29.327400 and did some few tests with this new HTTP_USER_AGENT code and seems is working fine :D:

Status:200, ResponseBody:<HTML><meta http-equiv="Pragma" content="no-cache"></head><body>7,1,23,1000,7,128,Alien Vampires - Humans=Cunts</body></html>

but i still got error on some few streamers like: http://sl_live_radio.net-radio.org:8167 - SL Live Radio : "URL passed to llHTTPRequest is not valid"

is this good news?

do we have to wait for further information about updates on sl servers? because that HTTP_USER_AGENT is still not valid on sl?

The problem is that the underscore character is not valid in a hostname. We'll see if we can relax the restriction.

Watch for new simulator releases; we'll update the Magnum channel Wednesday with the version that's now on those beta regions, and in time the fix will make it to the main channel

  • Like 3
Link to comment
Share on other sites

On 30.6.2017 at 4:07 PM, Oz Linden said:

It's our judgement that this wouldn't be a good idea. We think we've made changes that should allow updated scripts to work with most servers (see yesterdays post)

Yes, I read the other post and it's good that it mostly works again, but my suggestion was specifically about "not updated" scripts, and while I personally don't care so much about SHX, I know many use it and need to buy something else now (good for other creators like me, bad for customers). But I understand (and agree) it's not a good idea and would be just a messy workaround, so I guess SHX users just have to swallow the pill...

Still, "most servers" is a bit unsatisfying since we don't have much influence on their configuration. So I would be interested to know whether my other suggestion about an option HTTP_SKIP_DEFAULT_HEADERS or similar which would give scripters more control over the headers being sent would be considered a better idea, maybe in a later update. Thank you :-)

  • Like 3
Link to comment
Share on other sites

On 7/2/2017 at 7:26 AM, Linnrenate Crosby said:

I still get a 403 response from the shoutcast servers (this test was run with the http://bigdaddys.digistream.info:20368 stream). Funny thing i did notice is that apparently the old code do pull the meta data from shoutcast v1.x, but not from the newer v2.x - which Big Daddys are running.

 

The Shoutcast stream API has changed, and the /7.html is no longer supported. See http://wiki.shoutcast.com/wiki/SHOUTcast_DNAS_Server_2_XML_Reponses#Equivalent_of_7.html

  • Like 1
Link to comment
Share on other sites

23 hours ago, Shuichi Shinji said:

Still, "most servers" is a bit unsatisfying since we don't have much influence on their configuration. So I would be interested to know whether my other suggestion about an option HTTP_SKIP_DEFAULT_HEADERS or similar which would give scripters more control over the headers being sent would be considered a better idea, maybe in a later update. Thank you :-)

Because the X-SecondLife headers are useful in debugging the server and region (finding misbehaving objects), we won't provide an option to suppress them, but if it turns out that there are enough servers out there that the new fix (being rolled to the RC channels as I'm typing this) doesn't support, we'll consider other steps to take. Making that decision will require reports about what's not working. So far, I have not seen a report of a Shoutcast v1 server this doesn't fix (v2 does not support this api).

The fix being rolled now still does not allow underscores in the host name; I expect that we'll add that to some future version, but would not block this release from the main channel for that (I don't have the last word on that, though).

  • Like 1
Link to comment
Share on other sites

Tried following script on Second Life RC Magnum 17.06.29.327400:

key kSentRequest;
string URL;
string stream_status;

default
{
    state_entry()
    {   
        URL = "http://muddys.digistream.info:20398";
        llOwnerSay("URL:"+URL);
        kSentRequest = llHTTPRequest(URL + "/7.html",[HTTP_USER_AGENT,"XML Getter (Mozilla Compatible)"],"");
    }   
    http_response (key kRecRequest, integer intStatus, list lstMeta, string strBody)
    {
        llOwnerSay("Status:"+(string)intStatus+", ResponseBody:"+strBody);
    }
    on_rez(integer start_param)
    {
        llResetScript();
    }
}
 

RESPONSE:

HTTP_USER_AGENT 'XML Getter (Mozilla Compatible)' is invalid

Tried following too:

        kSentRequest = llHTTPRequest(URL + "/7.html",[HTTP_USER_AGENT,"XML Getter (Mozilla Compatible)\n\n"],"");

RESPONSE:

Same

Did I understand something wrong with the syntax?

Link to comment
Share on other sites

1 hour ago, Oz Linden said:

Because the X-SecondLife headers are useful in debugging the server and region (finding misbehaving objects), we won't provide an option to suppress them, but if it turns out that there are enough servers out there that the new fix (being rolled to the RC channels as I'm typing this) doesn't support, we'll consider other steps to take. Making that decision will require reports about what's not working. So far, I have not seen a report of a Shoutcast v1 server this doesn't fix (v2 does not support this api).

The fix being rolled now still does not allow underscores in the host name; I expect that we'll add that to some future version, but would not block this release from the main channel for that (I don't have the last word on that, though).

Ok, I do understand that and if you have other steps in mind that are better, I'm all for it :-) The script I am selling supports Shoutcast v1+2 and Icecast, so I will test them all once the new server version is rolled out and I have the time to do it, also with different URLs and I will report any issues. I did have problems with Icecast too when this started, so those servers might be affected too, unless it was another, unrelated issue.

Link to comment
Share on other sites

41 minutes ago, Emmerich Beeswing said:

Tried following script on Second Life RC Magnum 17.06.29.327400:

        kSentRequest = llHTTPRequest(URL + "/7.html",[HTTP_USER_AGENT,"XML Getter (Mozilla Compatible)"],"");

[...]

        kSentRequest = llHTTPRequest(URL + "/7.html",[HTTP_USER_AGENT,"XML Getter (Mozilla Compatible)\n\n"],"");

The example change Oz provided, included a "/1.0" after the user agent name (before the parentheses), I guess it's important. Your second try with the "\n\n" is definitely wrong, but the first should work with the added "/1.0" in my opinion.

Link to comment
Share on other sites

46 minutes ago, Emmerich Beeswing said:

Tried following script on Second Life RC Magnum 17.06.29.327400:


        kSentRequest = llHTTPRequest(URL + "/7.html",[HTTP_USER_AGENT,"XML Getter (Mozilla Compatible)"],"");
 

RESPONSE:

HTTP_USER_AGENT 'XML Getter (Mozilla Compatible)' is invalid

Did I understand something wrong with the syntax?

Spaces are not valid in a User Agent token.

Try 

[HTTP_USER_AGENT,"XML-Getter (Mozilla Compatible)"]

- even better would be ,

[HTTP_USER_AGENT,"XML-Getter/1.0 (Mozilla Compatible)"]

 

  • Like 1
Link to comment
Share on other sites

I did some tests and Shoutcast v1 servers seemed ok so far which is good news :-)

Icecast using the HTML status page also seems to work, the one using a JSON status page still needs to be tested (I didn't find one anymore), but that one should also be ok, I guess.

I do have an issue with at least one Shoutcast v2 stream: http://stardust.wavestreamer.com:8062

Checking in the browser is ok and also the XML status page http://stardust.wavestreamer.com:8062/stats?sid=1 which my script parses, but I only get a 403 error with no further information in the script.

Another Shoutcast v2 stream (http://www.ebm-radio.org:7000/) is working fine, though.

And I found a stream (http://74.208.197.50:8087/) which seems to offer Shoutcast v1 and v2 and it also replies with a 403 error while in the browser, v1 and v2 status pages work.

They are all working with the old server and script version.

Link to comment
Share on other sites

2 hours ago, Oz Linden said:

Spaces are not valid in a User Agent token.

Try 


[HTTP_USER_AGENT,"XML-Getter (Mozilla Compatible)"]

- even better would be ,


[HTTP_USER_AGENT,"XML-Getter/1.0 (Mozilla Compatible)"]

 

Ah yes thank you so much Oz and Shuichi :-) first tests running fine

  • Like 1
Link to comment
Share on other sites

1 hour ago, Shuichi Shinji said:

I do have an issue with at least one Shoutcast v2 stream: http://stardust.wavestreamer.com:8062

Checking in the browser is ok and also the XML status page http://stardust.wavestreamer.com:8062/stats?sid=1 which my script parses, but I only get a 403 error with no further information in the script.

They are all working with the old server and script version.

I tried that stardust wavestreamer manually with a few different variations; all returned 403. That status normally means "I know who you are, and you're not allowed to see that". Maybe you could ask the server owner why not?

Link to comment
Share on other sites

3 hours ago, Shuichi Shinji said:

I do have an issue with at least one Shoutcast v2 stream: http://stardust.wavestreamer.com:8062

Checking in the browser is ok and also the XML status page http://stardust.wavestreamer.com:8062/stats?sid=1 which my script parses, but I only get a 403 error with no further information in the script.

This script, which requests a json response and then uses the llJsonGetValue to parse it, worked with that server:


key kSentRequest;
string host="stardust.wavestreamer.com:8062";
string path="/stats?sid=1&json=1";
string stream_status;

default
{
    state_entry()
    {   
        string URL = "http://" + host + path;
        llOwnerSay("URL:"+URL);
        kSentRequest = llHTTPRequest(URL,[],"");
    }   
    http_response (key kRecRequest, integer intStatus, list lstMeta, string strBody)
    {
        string title = llJsonGetValue(strBody, ["songtitle"] );
        llOwnerSay(title);
    }
    on_rez(integer start_param)
    {
        llResetScript();
    }
}
 

In this case, adding a User Agent was not needed, but apparently some Shoutcast servers can be configured to either require or prohibit certain user agents.

  • Like 2
Link to comment
Share on other sites

Yes, it seems that omitting the user agent is the only change required to make it work with this server. Maybe it doesn't like 2 User-Agent lines or wants it in a different format. I used "Stream-Script/1.0 (Mozilla Compatible)", but it worked before with "LSL Stream Info (Mozilla Compatible)" in the old hack (which I can't try anymore because of the spaces).

Link to comment
Share on other sites

8 minutes ago, Shuichi Shinji said:

Yes, it seems that omitting the user agent is the only change required to make it work with this server. Maybe it doesn't like 2 User-Agent lines or wants it in a different format. I used "Stream-Script/1.0 (Mozilla Compatible)", but it worked before with "LSL Stream Info (Mozilla Compatible)" in the old hack (which I can't try anymore because of the spaces).

Apparently, the HTTP header just gets a little too long and omitting the custom user-agent is enough to keep the length within some limit. Using a shorter custom user-agent also works. So it's the header length again...

  • Like 1
Link to comment
Share on other sites

11 hours ago, Oz Linden said:

The Shoutcast stream API has changed, and the /7.html is no longer supported. See http://wiki.shoutcast.com/wiki/SHOUTcast_DNAS_Server_2_XML_Reponses#Equivalent_of_7.html

I have read both that 7.html went away with DNAS V2 and that it has since come back.  Can't say that I have excellent sources for this..  In my testing of some Shoutcast V2 servers 7.html gave me good results.  Not sure if those were exceptions.  Here's a link to a 2011 forum post saying 7.html came back due to popular demand: http://forums.shoutcast.com/showthread.php?p=3039066&langid=2

BTW, I made changes today at a Magnum sim and my revised scripts are working without problem now.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1505 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...