ab Vanmoer

Strange, I didn't receive any reply - but they have been restored for which I am pleased. Thanks, ab

I submitted my list of missing items 7 days ago, and have been checking my Markteplace store on a daily basis waiting for the items to reappear where I assumed they would, back in my Marketplace Store. After reading the above, despite not having received a reply to my Ticket letting me know that the items have been restored, I found them in Inventory-Manage Listings all are flagged as " (no version folder)" presumably I will now be able to re-list them via the Viewer. So even if you have not heard from Dakota, check your Inventory-Manage Listings they may be there.

@Linnrenate Crosby Thank you very much for the URL. It turned out to be a relatively simple change and now my Shoutcast display board supports all Shoutcast server versions up to and including V2.5 which is the latest version. I have sent you one of my boards as a gift - which you may, or may not find it useful Thanks, Ab

It is more than a little disappointing that the Linden's didn't find a way to maintain compatibility with existing scripts. I only learned of this problem yesterday for the first time when a tipjar script customer reported that the script was generating the "URL passed to llHTTPRequest contains a control character" error. Needless to say as soon as I was made aware of it I applied the fix to my script. However over the last few years I have sold hundreds of copies of that particular script, many to customers who were making and selling tipjars based on the script. It is highly probable that many of these creators have long since left SL leaving who knows how many customers with devices that not only will no longer function, but highly likely are still being sold on the Marketplace. I was not aware of the problem until now because my shoutcast display boards continued to operate flawlessly irrespective of the sim. Unfortunately however as needing more information than is available from 7.html I use a web page scraping technique which has been affected by changes in the various V2 Shoutcast server releases. V2.0 removed the 7.html and displayed a different server status page to the V1.9 status page. V2.2 restored the 7.html but also maintained compatibility with the V2.0 status page V2.4 kept the 7.html but changed the status page again. V2.5 is the current Shoutcast release, I am not aware of any stations that use it so am unable to check for changes to the status page or whether 7.html is still functional - presumably they have kept it. If anyone is aware of a station currently running V2.5 the URL would be greatly appreciated. Thanks, ab

LL has "sortof" fixed vwrsearch by redirecting it to search.secondlife.com - a completely pointless exercise because of the different behaviour between vwrsearch and search. vwrsearch required that new names include the "Resident" last name, whereas search.secondlife.com seems to return better results without the Resident last name, and more importantly the resultant pages are different enough that the screen scraping code has to be completely rewritten.

vwrsearch has been working for years now, but periodically LL breaks it and then one has to file a Jira to have it fixed. After breaking it on what seems to be an annual basis, they then take ages to fix it. Which is a pity, because for the rest of the time it is the most reliable, up to date and easiest way of getting name2key functionality. Unfortunately w-hat.com is not really a viable alternative, it is a third party web site that could disappear at anytime without warning (although despite earlier expectations, it has stayed up for years) but it is often out of date, whereas vwrsearch finds new avatars within hours if not minutes of them registering. As an alternative to using vwrsearch.secondlife.com one could use search.secondlife.com but the resultant web page does not seem to be consistent, so scraping it is a bit of a moving target.

Today Brooke Linden updated BUG-2104 (Changes to vwrsearch url breaks name to key functionality) as follows: We recently deprecated support for vwrsearch, a web page service that allowed getting the resident key from a web page. We recommend updating any products which used this service with a service that can provide this information. There are several options, some of which are listed here: Hosted services, such as w-hat ( http://w-hat.com/name2key) HUDs available on the Marketplace ( https://marketplace.secondlife.com/products/search?utf8=%E2%9C%93&search%5Bcategory_id%5D=&search%5Bkeywords%5D=name2key) We apologize for any inconvenience this has caused you. I responded: The alternatives you offer to vwrsearch are completely unacceptable, and indicate a complete misunderstanding of the requirements as well as the magnitude of the problem. Firstly, how exactly do you propose that I integrate the marketplace HUDS you link to into my vendors? Even if it was possible are you suggesting I buy a few thousand HUDS to distribute to my customers? Secondly, I know for a fact that many if not all the HUDS you link to actually use vwrsearch for their name2key lookup. Thirdly w-hat is a 3rd party service that offers no obligations, is often out of date, and may be withdrawn at any time on the whim of the owner. It is not an acceptable alternative where long term reliability is a concern, although ironically it now appears that it is probably far more reliable than Linden Labs. Although MartinRJ's workaround has been a welcome temporary workaround, it is unfortunately not a long term solution, firstly due to the already mentioned inability to find users hidden from search, and also because historically the search web page format is more likely to change than the vwrsearch pages that have remained static for years. I can not believe that it has taken nearly TWO months of uncertainty and the best that you can come up with are a few completely unworkable suggestions!. These suggestions did come as a bit of shock, not only because of their impracticality, but also because I thought that vwrsearch had been fixed as it has been working reliably once again for at least the past week! Yet another indicatior that LL doesn't have a clue as to what they are doing!! ab

Dahlia, Unfortunately LL in their wisdom (or rather complete lack thereof), decided that their paying customers are not mature enough to understand why LL simply can't be bothered to fix bugs or to even keep their paying customers updated as to the status of these bugs. So, at some point LL changed the JIra system; now only the person who opens a Jira is able to see it., that way they don't have to bother fixing bugs because they can pretend that each bug only affects one person. Older Jiras however are still visible though. It may be helpful if every one affected by this bug opens a new Jira, it might just kick LL into some action, to save effort when creating a new Jira, just copy and paste from the old - WEB-2362 It is really unusual to find a company that has managed to stay in business while treating its customer with the kind of contempt that LL reserves for its customers. This is a huge bug that affects thousands of people and LL can't even be bothered to let us know if they have any intention of ever fixing it. The last time it broke three years ago, LL took it seriously enough to have it fixed in one day. Current staff JUST DON'T CARE!

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

Pamela Galli wrote: The emails have changed back to "service" again. I missed the memo. Again. Only the 4th and they have completed a WHOLE month's work I hope that they aren't completely shattered when they have to roll it ALL back again weeks from now!

Wow, that must be so disheartening for the commerce team, a whole months worth of work rolled back

Thanks Pamela

It's official - the sales notification from email address has changed - http://wiki.secondlife.com/wiki/Release_Notes/Marketplace_Current#Release_Notes_for_Current_Marketplace_Release All the important marketplace functionality that is still missing or broken and the best that LL could come up with is a stupid change that only serves to mess up merchant's email filters :matte-motes-angry:

Sassy Romano wrote: Well... the architecture is broken because there are non transactional operations and by transaction here, i'm using the term "transaction" in the atomic defintion of it either completing in full or rolling back. The issue with MP is that a MB could send an item and THEN FAIL to communicate back to the back end just as easily as there be a forward failure of the back end to communicate with the MB to send an item. Once that return failure exists, the back end now is potentially in a holding state waiting for a retry of a timeout and in the case of a timeout, the MP back end could refund the customer. I have on more than one occasion seen a payment appear in my transaction history long before receiving the magic box delivery message. This would indicate that the MP is not waiting for a notification from the box before completing the transaction. There may of course be other reasons for things being reported out of sequence .... but as you so rightly said, as mushrooms all we can do is speculate.

Zanara Zenovka wrote: Welcome back Ab! Just wouldn't be a decent migration nightmare without you! Thanks Zanara, Arwen, WADE1 and everyone else Not really back just sticking my head above the parapets :smileywink: I took the last migration far too personally, putting far too much unproductive time and effort into trying to browbeat the commerce team into behaving professionally. And in the end it was all for naught, the Marketplace went ahead bugs and all while the merchants were left scrambling, trying to correct failed migrations and redoing listings to comply with the reduced functionality. To this day a large percentage of the bugs and the majority of feature requests languish in the Jira, completely ignored by the Lab. And considering that the majority of feature requests were requests for important functionality that had previously existed in xstreet, which LL have chosen to completely ignore, many of which a half competent programmer could have implemented in a few hours, seems to me to be a clear indication of the low regard the commerce team has for the merchants.