DJ Board Display Not Working Properly

[Oz Linden]

2 hours ago, Linnrenate Crosby said:

i guess it's time to nudge @Oz Linden and check if they made a new silent change to llHTTPRequest that cause this error.

Nope.

I queried the URL you posted and got back reasonable looking XML, so I suspect the public/private setting is the real issue.

[Linnrenate Crosby]

Thank you Oz, good to know nothing has changed with the lsl command.

@West Habercom I tried with 2 more streams hosted by you (aka digistream.info) http://poppysplace.digistream.info:11436 and http://muddys.digistream.info:20398 Both are running and streaming music and both give me the the same error as i posted previously. So i guess this is your mess, something has changed on your servers that prevent SL devices to pull the stream data from them. You provided me a link to http://stream.classicrock109.com:10042 which worked fine with my script, no wonder really as it's not hosted by your company. Please fix the mess you created as i see more people will complain as it will effect a lot of stream boards in SL... not just mine that i don't sell or give away. If you need to debug more yourself just grab my script, place it in a prim.. .no deeding are needed - touching the prim will reset the script and cause it to pull the data again.

[West Habercom]

30 minutes ago, Linnrenate Crosby said:

Thank you Oz, good to know nothing has changed with the lsl command.

@West Habercom I tried with 2 more streams hosted by you (aka digistream.info) http://poppysplace.digistream.info:11436 and http://muddys.digistream.info:20398 Both are running and streaming music and both give me the the same error as i posted previously. So i guess this is your mess, something has changed on your servers that prevent SL devices to pull the stream data from them. You provided me a link to http://stream.classicrock109.com:10042 which worked fine with my script, no wonder really as it's not hosted by your company. Please fix the mess you created as i see more people will complain as it will effect a lot of stream boards in SL... not just mine that i don't sell or give away. If you need to debug more yourself just grab my script, place it in a prim.. .no deeding are needed - touching the prim will reset the script and cause it to pull the data again.

Actually, that classic rock 109 stream is indeed on our server server.. We have not made any changes or updates to our server in well over a month. So if it you started having issues last week, it certainly did not come from our end. So, as with anything else, if it worked with your script, the others should as well, unless the datacenter for some reason has blocked  a set of SL IP numbers (which they have done in the past)

I will add that muddys and bigdaddys, while using the same shoutcast version, are on different boxes.  Again, we have not done any updates (yet) in over a month but they do run the same shoutcast version.

All v2 server are by default set to private. the common them between the poppys, big daddys and muddys is they are all set to private.

To assume "we" have "created a mess" is just wrong.  We" haven't done anything of the sort. As I mentioned we haven't touched those servers in s\well over a month. If it works 2 weeks ago, then it should still work. Nothing has been done to create this issue on our end.

Radios in SL connect fine. Software used outside of SL show information properly in terms of what is playing, even SL shows "Now Playing" correctly. So no, we have not "created this mess".

[West Habercom]

I just asked a friend who is in-world to check for me. Both places they went to showed our radio station playing... both stations are on the same servers that our SL clients are on. The only different is, the SL clients are set to Private, and the radio station are set to Public. 

She took screen shots and sent to me - here they are.The boards are from Daffy Proto and SHX

[Shuichi Shinji]

I don't think that public/private setting has any relevance here. Getting the stream info in a browser works, getting it in SL doesn't. Both send a HTTP request including the URL and some headers before. Additionally, the "client" IP is different (actual client IP in case of browser, some SL server IP otherwise). So the logical conclusion would be that something is blocked on the server side, either by IP or something in the headers, probably user-agent or another header indicating the request is coming from SL. Maybe ask the datacenter, especially if they have done something like that in the past already?

[Shuichi Shinji]

33 minutes ago, West Habercom said:

I just asked a friend who is in-world to check for me. Both places they went to showed our radio station playing... both stations are on the same servers that our SL clients are on. The only different is, the SL clients are set to Private, and the radio station are set to Public. 

Do you know if the other streams work on those boards, too? I can access classicrock109 just fine with my script, but not the other ones. Would be interesting to see whether they work or not on the boards. They do work from a browser.

[Linnrenate Crosby]

47 minutes ago, West Habercom said:

I just asked a friend who is in-world to check for me. Both places they went to showed our radio station playing... both stations are on the same servers that our SL clients are on. The only different is, the SL clients are set to Private, and the radio station are set to Public. 

She took screen shots and sent to me - here they are.The boards are from Daffy Proto and SHX

Well West, i did say that http://stream.classicrock109.com:10042  worked for me too. You should have had your friend test any of the other 3 streams i gave. I do hope Shuichi are right about the SL ip's has been blocked still the only person that can get that sorted out are you and your hosting company.

[West Habercom]

9 minutes ago, Shuichi Shinji said:

I don't think that public/private setting has any relevance here. Getting the stream info in a browser works, getting it in SL doesn't. Both send a HTTP request including the URL and some headers before. Additionally, the "client" IP is different (actual client IP in case of browser, some SL server IP otherwise). So the logical conclusion would be that something is blocked on the server side, either by IP or something in the headers, probably user-agent or another header indicating the request is coming from SL. Maybe ask the datacenter, especially if they have done something like that in the past already?

I am ahead of you. I asked if they have done any of that to any of our servers hosted with them. They say "no".

[Shuichi Shinji]

1 minute ago, West Habercom said:

I asked if they have done any of that to any of our servers hosted with them. They say "no".

Thank you for asking. The cause remains unknown, though. What's the actual difference between the stream that works and the others, apart from public/private? Or, what effect does public/private have in regards to answering an HTTP request? And even then: why did it suddenly stop working? (Not blaming or pressuring you, just curious what caused it.)

[Linnrenate Crosby]

Someone must have been looking into it West, because now all of the sudden i got a working board again

[West Habercom]

If they are I havent noticed. M<y friends tried it added it to her board as a dj didnt work... then all of a sudden added it as a station and it worked.

Unless datacenter, after my call did an "oops" (and weren't honest)?

Edited January 16, 2020 by West Habercom

[Linnrenate Crosby]

We'll just settle for them doing the "oops"  and double checking Thanks for helping out sorting this for us West.... and i'm sorry for nagging you so much

[Kacey Delicioso]

not sure why you would blame a STREAM PROVIDER for an SHX issue - does your stream work?  if yes, its not the stream provider

if your shoutcast board isnt working, its a SHX issue or USER ERROR 

get rid of it, no one uses the boards anymore, all your songs show in local chat (if your broadcaster is set right)

[Shuichi Shinji]

Works for me again as well. Thank you for asking and maybe it was an oops, who knows.... happens ^^

@Kacey Delicioso It was not an SHX issue because other scripts requesting stream info also didn't work. The streams themselves worked, but not the stream info (if requested by script, i.e. from an SL server IP, not a user client IP... because the latter also worked). And it was only streams from this stream provider as far as I know (and maybe only a few), so assuming it was something on their side was justified. It was definitely no SHX issue and no USER ERROR. And announcing song titles in chat is not a feature of all viewers btw.

[Kacey Delicioso]

still not a stream provider issue

[Shuichi Shinji]

1 minute ago, Kacey Delicioso said:

still not a stream provider issue

Yes, of course you are right, I am terribly terribly sorry.

[Daffy Proto]

first of all i want to thank everyone about this attempt was made to solve the problem.

there is one of my clients which uses a same digistream with the same actual problem and still after working on the DG-X Boards

i had no luck and the problem was remain but and all of a sudden (oops lol) seems digistreams are working in general. 

i made many tests with different digistreams and the issue return to normal....thank you everyone

streamers i was testing and successfully work now:

http://ohana.digistream.info:10288 ,  http://poppysplace.digistream.info:11436 , http://muddys.digistream.info:20398

thanks in advance and congratulations for the good work - daffy proto

 

[Linnrenate Crosby]

16 hours ago, Kacey Delicioso said:

not sure why you would blame a STREAM PROVIDER for an SHX issue - does your stream work?  if yes, its not the stream provider

if your shoutcast board isnt working, its a SHX issue or USER ERROR 

get rid of it, no one uses the boards anymore, all your songs show in local chat (if your broadcaster is set right)

So if you cannot logon to SL because the grid are down (because of their hosting company has problems) you don't create a support ticket about the problem. Instead you assume your PC are broken, throw it away and buy a new one and again assume you can get connected?

That's wrong, the closest contact to the hosting company are Linden Lab.... or as it was in this case, the stream providor (which i might add got this problem sorted out very fast).

[West Habercom]

AHA! We figured out why this was happening on SHOUTcast boards, and to be transparent about things I wanted to reply one more time to let everyone know..

It seems that the IP number trying to fetch the information from the servers, belonging to Linden Lab) registers on a v2 server as a stream saver (aka potential ripper), believe it or not. One of our engineers had written a script where enough of these attempts by an IP number labeled this way ends up getting banned from the server:

I have X'd out the IP protect Linden Lab

2020-02-03 07:14:00 INFO [DST XXX.XX.XX.XXX:24650] Stream savers not allowed

IP Location	United States Of America San Francisco Linden Lab
ASN	ASXXXXX LINDEN-LAB, US (registered Nov 20, 2007)
Resolve Host	sim10597.agni.lindenlab.com
Whois Server	whois.arin.net
IP Address	XXX.XX.XX.XXX

NetRange:       XXX.XX.X.X -  XXX.XX.XX.XXX
CIDR:           XXX.XX.X.X/18
NetName:        LINDEN
NetHandle:      NET-XXX-XX-X-X-X
Parent:         NET216 (NET-XXX-X-X-X-X)
NetType:        Direct Assignment
OriginAS:       ASXXXXX
Organization:   Linden Lab (LINDE-3)
RegDate:        2008-02-04
Updated:        2012-02-24
Ref:            https://rdap.arin.net/registry/ip/xxx.xx.x.x

The way we had this setup, after X number of attempts from a "stream saver" to connect eventually lands that IP number as banned on the server.  This was found out when the initial question came up and I had mentioned it to one of my engineers at the office. She found the issue and removed the banned, which is when the boards started working. I didn't know she had done that, because I wasn't in that office at the time, and that led me to beiieve the datacenter had not been honest with me.

I made the decision the following day to have the script removed and allow SHOUTcast to do it's job without help from us.

To those that had the issue with their boards, I apologize. Sometimes we make decisions that we feel are right, and they end up being the incorrect. I'm sure we've all been there. I never thought a Linden Lab IP number would be listed as a "Stream Saver". In the end, the boards should now work well.

 

West Habercom

digiSTREAM SHOUTcast Hosting
Classic Rock 109
Classic Hits 109 (4 Radio Stations: 70s, 70s-90s, Country, Yacht Rock)

Edited February 3, 2020 by West Habercom

[Oz Linden]

7 minutes ago, West Habercom said:

It seems that the IP number trying to fetch the information from the servers, belonging to Linden Lab) registers on a v2 server as a stream saver (aka potential ripper), believe it or not. One of our engineers had written a script where enough of these attempts by an IP number labeled this way ends up getting banned from the server:

I have X'd out the IP protect Linden Lab

For future reference; if anything in your infrastructure relies on simulator IP addresses being in a particular range or having a particular domain name, you should reconsider it - when the simulators are in the cloud (none you can see are, yet) both of those will change.

[Lucia Nightfire]

5 hours ago, Oz Linden said:

For future reference; if anything in your infrastructure relies on simulator IP addresses being in a particular range or having a particular domain name, you should reconsider it - when the simulators are in the cloud (none you can see are, yet) both of those will change.

Is scripted url requesting going to change in the future in that respect? IE, are url's generated by llRequestURL() & llRequestSecureURL() going to have any structure change, particularly, ".agni.lindenlab.com" & ".aditi.lindenlab.com" or are there going to be new functions by then?

[Oz Linden]

13 hours ago, Lucia Nightfire said:

Is scripted url requesting going to change in the future in that respect? IE, are url's generated by llRequestURL() & llRequestSecureURL() going to have any structure change, particularly, ".agni.lindenlab.com" & ".aditi.lindenlab.com" or are there going to be new functions by then?

The functions will not change; the values returned by them will, since we won't be using the 'lindenlab.com' domain for simhosts in the cloud (they'll probably be in 'secondlife.io'). They will most likely still have the grid level in the name, but I strongly recommend not counting on any particular structure or content in the value.

[Lucia Nightfire]

1 hour ago, Oz Linden said:

The functions will not change; the values returned by them will, since we won't be using the 'lindenlab.com' domain for simhosts in the cloud (they'll probably be in 'secondlife.io'). They will most likely still have the grid level in the name, but I strongly recommend not counting on any particular structure or content in the value.

There should probably be some kind of public statement and a sticky thread in the scripting subforum about that hopefully along with an example of what the next structure is going to be way ahead of the change as there is most likely a ton of content in the wild verifying expected structure. There have been problems with those functions in the past returning incomplete structure during capacities failure along with other random issue.