Jump to content

vwrsearch.secondlife.com is down


Norton Burns
 Share

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

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

Recommended Posts

The 'old search' was announced as depreciated the same time the 'new search' was brought in with Viewer 2. It's only been running on LL's good graces all this time (and the fact that many V1 viewers still were in use).

But now that Phoenix and other V1 based viewers have dropped to negligble usage levels, I expect LL has finally decided to pull the plug.

Link to comment
Share on other sites


Norton Burns wrote:

Thank you for stating the obvious - without the faintest idea as to what the subject was & why the previous comment was smug, wrong & not at all helpful.

Only it wasn't. It was factual, and matter of fact.

You can choose to live in your fantasy world, no skin off my nose. But I would adivse others to simply start using the new search instead of crying over the loss of the old.

 

The new URL is http://search.secondlife.com/viewer/search  There's very little you can't do with it that you could do with the old.

Link to comment
Share on other sites

The problem is, though, that a lot of people -- rightly or wrongly -- have been using this to get avatars' uuids, as an alternative to databases like w-hat.   If it's broken for good, then it's broken for good and we'll have to think of an alternative, but if -- as has happened several times in the past -- it's been broken by accident and LL don't mind fixing it to keep content running, that would be delightful.

Either way it would be good to have a definitive answer.   I don't want to start rescripting stuff if LL are going to fix the issue in the next day or so.  But if it's been broken on purpose, it would have been nice to get a bit of notice.

Link to comment
Share on other sites

search 1.jpg

search 2.jpg


Darien Caldwell wrote:


Norton Burns wrote:

Thank you for stating the obvious - without the faintest idea as to what the subject was & why the previous comment was smug, wrong & not at all helpful.

Only it wasn't. It was factual, and matter of fact.

You can choose to live in your fantasy world, no skin off my nose. But I would adivse others to simply start using the new search instead of crying over the loss of the old.

 

The new URL is
  There's very little you can't do with it that you could do with the old.

You may be right about "There's very little you can't do with it that you could do with the old," but at least using the new In World, the UI is clunky, unintuitive and anything but user friendly.

I post the above as an example.  I am trying to find someone but am uncertain of their full name.  In this instance I used my first name, Perrie.

I can accomplish the task in a tenth the time with the legacy search.

So I am not going to stop crying over this Linden initiated travesty they call "new search."

While it is true I'm going to have to learn to live with it, I'm still going to call it what it is. A piece of crap.

 

Link to comment
Share on other sites


Innula Zenovka wrote:

The problem is, though, that a lot of people -- rightly or wrongly -- have been using this to get avatars' uuids, as an alternative to databases like w-hat.   If it's broken for good, then it's broken for good and we'll have to think of an alternative, but if -- as has happened several times in the past -- it's been broken by accident and LL don't mind fixing it to keep content running, that would be delightful.

Either way it would be good to have a definitive answer.   I don't want to start rescripting stuff if LL are going to fix the issue in the next day or so.  But if it's been broken on purpose, it would have been nice to get a bit of notice.



NOTICE?   From LL?  That they are going to break something?   Or than something not obvious - such as logins- is broken? Seriously?    What are you some kind of cockeyed optimist?   LL provide useful LSL calls llAvatarName2uuid(string name)?  Fat chance.   Pardon my cynicism.

EDIT:  fix italic

Link to comment
Share on other sites

In the past, when LL have broken scripts that scrape LL webpages,  it's always turned out to be by accident and they've normally fixed it in a few days.   Similarly, when they've intended to break stuff -- e.g. posjump or the llVolumeDetect hack to phantom child prims -- they've given us some warning.   

Apart, maybe, from invisiprims, I can't offhand think of an example of something they've done that's broken a lot of content that they haven't either fixed or done something to mitigate, at least not without warning us that was going to get broken.   

Did you have an example in mind?

Link to comment
Share on other sites

I can't code in PHP or Python...and rely on a Name2Key Google App API written in Python that used vrwsearch...so this is a big deal for me...


After some searching....Found Some PHP code that uses the Search.secondlife.com site...Problem I see with this one is that Search.Secondlife.com

(Example: http://search.secondlife.com/client_search.php?session=00000000-0000-0000-0000-000000000000&q=XAVIER%20SOCKINGTON ) comes back with a list of all Groups, and Avatar profiles that have the name you search for in it....then you have to select the search result that is the person's name - and the website URL of the user profile (after you click their name) is their UUID Key....

 

This website has some php coding with may help in generating a new Key2Name app based on the Search.secondlife website...  http://wiki.secondlife.com/wiki/User:Jor3l_Boa/PHP/n2k.php

If anyone creates a Python Google App Engine Using this - please do poke me and let me know - it would be appreciated!

Thanks all

Link to comment
Share on other sites


Innula Zenovka wrote:

In the past, when LL have broken scripts that scrape LL webpages,  it's always turned out to be by accident and they've normally fixed it in a few days.   Similarly, when they've intended to break stuff -- e.g. posjump or the llVolumeDetect hack to phantom child prims -- they've given us some warning.   

Apart, maybe, from invisiprims, I can't offhand think of an example of something they've done that's broken a lot of content that they haven't either fixed or done something to mitigate, at least not without warning us that was going to get broken.   

Did you have an example in mind?

I can think of one. In fact, this current example is quite reminiscent of that MapAPI breakage for in-world scripts. Not all that many scripters use the functionality, but it's not entirely obscure, having worked for years, and the only alternative is to add an extra round-trip over the internet to access an external server.

The main difference being that the broken MapAPI functionality was--and, in fact, still is--documented on a Lab-official wiki page.

Link to comment
Share on other sites


Innula Zenovka wrote:

In the past, when LL have broken scripts that scrape LL webpages,  it's always turned out to be by accident and they've normally fixed it in a few days.   Similarly, when they've intended to break stuff -- e.g. posjump or the llVolumeDetect hack to phantom child prims -- they've given us some warning.   


Hi Innula,

I noticed this was down on March 27th and filed a Jira, it's the first Jira I have filed in ages, so I was unpleasantly surprised to find that Jiras are now only visible to the person who files them. Any way in response I received this message from Alexa Linden the next day:

Alexa Linden commented on BUG-2104:Hi ab, can you tell me the last time you knew this was working properly?  I'm trying to narrow down the cause.  Thanks!

Which would support your supposition that it was broken accidentally. Unfortunately I have heard nothing since :(

Although as suggested earlier in this thread, it should be possible to use search.secondlife.com, one can not rely on the format of the web page being stable, so scraping code would have to be updated as the page changes. LL gave us vwrsearch.secondlife.com in August 2009 as a supposedly stable alternative after changes to search.secondlife.com broke scraping code.

ab

 

 

 

Link to comment
Share on other sites

As of yesterday or the day before, http://vwrsearch.secondlife.com/client_search.php is failing to return search results. This is extremely bad and is no doubt breaking many many scripted objects in SL, mine included. Please note that http://search.secondlife.com/client_search.php is NOT a viable alternative for scripters. It DOES NOT return correct legacy names in the search results in all cases. If the avatar you are searching for has a custom name set, it will NOT return the legacy name, nor is it available on the world.secondlife.com search results if you try following those links. One vital function that vwrsearch is the only working option for is getting correctly spelled and capitalized LEGACY names, which every subscriber messaging system in the universe uses. Even more critical is that you can get search results that are NOT MATCHES of your search name, which is absolutely terrible. Misspelled names will result in search results for different or non-existant avatars that are spelled close to the searched for name and no easy way to confirm that you got the right key since the legacy name is not guaranteed to always be in the search results. This is a problem for anyone like me that maintains a huge database populated by names and keys from non-authoritative sources (such as hand-collected lists of misspelled avatar names that need to be confirmed and corrected on adding to the database). If you do get a search result for someone that happens to have a custom name, you get very different results - their username followed by their account name in parens, which could be used to confirm that you got the right person, but again, you don't get the account name in all cases. In that case, you get the legacy name. This is pretty bad, LSL developers REALLY need an authoritative avatar key/name lookup service that doesn't go down, ever, and returns sane search results that belong to the avatar you're actually searching for and don't require crazy complicated processing to figure out if your search results are even valid.


For those scripters out there frantically converting to use search.secondlife.com like me to keep products working in the interim (sigh) here are a few tips. When parsing the search.secondlife.com results, which may or may not be multiple people, following the key in the <a> tag href, you get either 1) a legacy name or 2) a username followed by an account name in parens. Parse appropriately and you can do some level of confirmation of search results by comparing the original searched-for name with the account name, or if the name comes back with no parens, then it must be a legacy name. In both cases you can do a case insensitive comparsion and confirm that you've got the key to the person you're actually looking for. And don't for get to include a &s=people parameter in the search string to limit your results to just avatars.


A few regular expressions to help:

@"world\.secondlife\.com/resident/(.{36})""\s*>(.+)</a>" will extract the returned key and the avatar name, if any avatar search results come back.

Use @" \((\w+)\.(\w+)\)" to test to see if the returned name is an account name and give you the first and last names (in lower case) that you can then compare separately to confirm.

If that doesn't match, then you probably got a legacy name, not an account name. Just do a case insensitive comparison on the whole name from the first regex above and if it matches your search name, you're good, and the returned name has correct capitalization.

Link to comment
Share on other sites

Considering how long this has now been down, I can imagine this will be a permanent change. The last time this happened it was fixed same day. This one has been an issue going on a week and a half at this point.

 

I started noticing this issue as of 2013-03-26 04:13:53 so sometime after midnight on March 26th it began returning no responses.

 

You can utilize the new search (albeit not as clear as the old search since now you get a bunch of display names entangled in your results as well as lack of new avatar keys) via http://search.secondlife.com/client_search.php?session=00000000-0000-0000-0000-000000000000&mat=7&q=[query_here]

 

mat=7 ensures you return avatars whos profiles are flagged adult. Without this, they do not appear in your results unlike via vwrsearch.

s=People ensures only avatars are returned.

 

You can review the different sections of the API via http://wiki.secondlife.com/wiki/Search_API just be aware this is not guaranteed to work as nothing ever is. vwrsearch to grab uuid's was a hack since Linden Lab does not provide that functionality. (it would be absolutely fantastic to have a reliable way to do so via username! *hint hint*)

 

We shouldn't expect it to work at all and the fact it does is simply a miracle at that.

Link to comment
Share on other sites

This turned out to be more complicated than I thought. If the returned avatar has a legacy last name  of "Resident", then the account name is just a single word, so you need to distinguish account names that do and do no have a "." in them. For example Joe Resident with a username of "JOE" will return "JOE (Joe)", but an avatar Joe Bloe with username of "JOE" will return "JOE (Joe.Bloe)". Good luck to you guys trying to parse this mess, jeez.

Link to comment
Share on other sites

Here's a good example. Let's say you're searching for an avatar with a legacy name of "Tula Resident". If you search on the account name, that is simply "tula" (parens are not part of an SL account name nor are parens always returned around account names in search results). So if you do http://search.secondlife.com/client_search.php?s=People&q=tula

You'll notice that the first search result is not the correct avatar, so gotcha #1 is that you MUST search the entire result set. In fact, this search returns multiple pages! And the correct avatar with account name = tula is not even on the first page, so your web application needs to keep loading and parsing an undefined number of pages looking to confirm your search results.

God forbid you search for an actual resident with an account name of "secondary" because you'll get 8 PAGES of search results, for every person with that word anywhere in their profile. This is simply not useable for real products that need to do a definitive name to key lookup without putting unnecessary and completely useless strain on the search servers, not to mention how tricky it is to do it right, which translates to  lots of product bugs as you figure out all the crazy weird gotchas involved in search.secondlife.com (trust me, ugh) or incorrect keys. Someone testing this may never notice that it's possible to get multiple names in a search result, not to mention multiple PAGES, if every test name you ever test with only ever returns one search result. That's a bad assumption that I could easily see someone making, and now you've populating a database with BAD data, which is the worst possible situation.

Link to comment
Share on other sites

"Tula resident" doesn t exist ... ( or had been purged after a delete of her account)

So it s normal that the sort by relevance gives something else for the 1st name of the list

 

So you don t need to parse every pages

 

Anyway vwrsearch could not check if an avatar has been purged or not. And you needed a proxy to use vwrsearch

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3992 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...