[UPDATE: April 5, 2012] We’ve identified two issues contributing to WEB-4587.
The first issue concerns mismatched data appearing on Marketplace listings. This impacts a very limited number of Merchants and has been occurring since the original migration from Xstreet to the Second Life Marketplace in September 2010. We continue to actively work on a resolution.
The second issue concerns incorrect listings appearing in search results. We have identified the issue and are actively working on a fix.
The information provided by Merchants on the forum and directly to the Marketplace development team helped greatly in identifying the root cause of these issues. Thanks to those who provided information.
We will continue to provide updates as we work through the issues.
There is no indication as to haw far along any resolution / fix for either issue might be – and probably wisely so. Event tentative dates might be taken literally and cause additional strain in LL / merchant relationships if missed.
That one of the errors dates back to the original migration from XStreet to the current SL Marketplace back in 2010 will come as no real surprise to merchants who have been impacted by the issue; it is a view that was aired as a part of ongoing discussions into the matter. It might event be fair to say – as the update hints – that it was such speculation and investigations by merchants themselves that may have helped Linden Lab confirm this particular root cause for the problems.
Even without potential dates for a fix or fixes to be rolled-out, the feedback from the Lab is to be welcomed. Hopefully, now issues have been identified and the line for updates has been re-established, the Commerce Team will take further steps to ensure the merchant community as a whole is kept informed of the situation through the Commerce forum.
Merchants are continuing to investigate the listing errors occurring on the SL Marketplace, with several confirming a suggestion put forward by Argus Collingwood on March 31st, and again suggested today that the issue appears to impact products with listing numbers in the 14xxxxx range. This has also been reported through the JIRA (WEB-4587)
It is currently unclear as to whether Linden Lab are looking into the possible connection, as apart from direct e-mails / e-mails with a handful of those impacted, the Lab and the Commerce Team remain largely silent on the issue.
Which is not to say they are sitting on their hands. As reported in an update here as well as on other blogs, the Lab has made a number of positive moves: extending the deadline for Direct Delivery migration /Magic Box retirement to the start of June; cancelling the overall timetable associated with DD originally published in the DD migration guide, and listing those JIRA they are actively pursuing. Merchants have also received assurances that LL are working to correct issues within support that have led to misleading or incorrect information being supplied to Merchants who have filed tickets on problems in direct response to requests from the Commerce Team.
However, the problem remains one of a need for more direct two-way communications. LL are assuring people the listing issue is being addressed as a “top priority”, yet the amount of information coming out of the Lab is limited. There has been no input to the JIRA from LL since March 29th – and no response to the idea of the issues being focused on items with listing numbers in the 14xxxxx range. Such is the silence of the Lab, that people are wondering if the associated forum thread is being read, and are trying to direct feedback to the JIRA to try to ensure it is being seen by the Lab.
As it stands, Merchants are trying to figure out matters and provide potential pointers to assist the Lab. The theories may be correct, or may be down to bizarre coincidence – and if correct, it’s entirely likely that the Lab have already made the connection and is working toward a solution. But given there is no concise feedback coming out of the Lab at all on matters, Merchants are still very much being left in the dark and to what might be the case.
Given the effort they are themselves putting into the matter, Linden Lab could at least meet them half-way and provide some form of feedback on what is happening and how useful the pointers may be. As I’ve said previously, detailed explanations are not required; but more direct feedback can only be a positive move on LL’s part on at least two counts:
It will reassure those worried about whether Merchants’ own feedback is being read by the Lab and looked into (if not already under investigation)
It will help underline the Lab’s commitment to resolving issues and working cooperatively with Merchants to address issues.
For the last several days, there has been a serious issue with the SL Marketplace. I’ve reported, with updates, on the matter – as have others. The problem, which as I’ve noted in my original blog post, includes:
Listings on Marketplace stores do not match the actual items
Incorrect merchant attribution (products from Merchant X listed as belonging to Merchant Y, despite appearing in Merchant X’s store)
Products from one merchant appearing in stores belonging to other merchants
Items incorrectly priced
Incorrect ratings assigned to products (G-rated items appearing as Adult, etc.).
Note that a full list of JIRA on Marketplace issues is also available via Sera Lok and Sassy Romano.
Advice and feedback from the Lab on the issue has been sporadic at best. On the plus side, we have had a welcome apology for errors in the support team relating to the issue. However, feedback within the forum thread on the issues has otherwise been restricted to an attempt to provide advice on the issue which unfortunately, it doesn’t appear to work. Elsewhere, feedback has been restricted to a brief Grid Status page remark.
And therein lies a problem: many are completely unaware that there is an issue. As a result, we’re starting to see:
Rising levels of accusations of “theft” among merchants as they come across what appears to be their own goods being listed by others
Well-intentioned customers raising concerns of product theft with merchants when they see incorrectly listed items
Growing concerns and confusion being voice through various product support groups in-world.
Linden Lab are somewhat caught between a rock and a hard place here. They are obviously trying to resolve the situation as quickly as possible, and in a manner that won’t in itself lead to further issues and problems: hence why calls to suspend the Marketplace appear to have gone unanswered. We simply do not know the extent of the issue and it would appear that there are at least as many merchants unaffected by the problem (such as myself) as there are merchants impacted by it. Therefore, it is entirely possible that were LL to suspend the Marketplace, the resultant uproar might be even greater than the upset the issue itself is causing.
However, LL do need to be more proactive in communicating the issue – not all merchants routinely read the Merchant’s forum and not everyone reads the Grid Status pages (unless there is something very noticeable “going wrong” in-world, such as teleports failing, rezzing issues, etc). Hence why the levels of misunderstanding are growing.
If the issue cannot be easily resolved – and this would appear to be the case, then more direct communication on the matter – via e-mail, through all available channels such as the Land and Business blog, etc., would appear to be of an increasing necessity. The e-mail / blog post doesn’t need to delve into specifics but should at least outline the problem and indicate that the Lab is actively seeking to resolve the issue. Doing so would ensure merchants are informed, and potentially go a long way to stemming accusations of “theft” and / or fear of “copybotting”.
On a broader front, being seen to provide information would also help stem the rising tide of anger being directed at the Lab over this issue. Alongside the calls to suspend the Marketplace have also been calls to roll back the Marketplace database to a prior to this problem arising. There are more than likely practical reasons as to why this cannot be done; however, by not acknowledging such calls and at least outlining why a roll back cannot be done – or why there needs to be further investigation prior to committing to a roll-back if it turns out the idea is feasible – would again so much to lessen the resentment that customers are feeling towards the Lab at this point in time.
It is again in situations like this where Linden Lab do themselves no favours, something I’ve recently touched upon. There are times when silence simply doesn’t work – yet all too frequently, silence is the main tool the Lab uses in dealing with a situation. It’s also an approach that reinforces the negative attitude many people feel towards the Lab, justified or otherwise.
Linden Lab has channels of communication open to it – and where e-mail is concerned, it’s not as if they’ve not used that channel to reach out to merchants in the past. Given the fact that even now, three days after the initial problem was first noticed, some people are still only just finding out about the problem – and in some cases leaping to the wrong conclusion – an advisory posted to the blog and / or e-mailed to merchants would seem to be a practical step to take, particularly as we are now facing the weekend with absolutely no indication as to whether the matter will be resolved sooner rather than later.
Update 23:40BST: Sassy Romano and Sera Lok have published a list of JIRA related to this and other core Marketplace issues (including Direct Delivery).
Update 23:20BST: It is still being reported through various forums and blogs that LL have “stopped” supporting Magic Boxes. This isn’t the case; rather, there appears to have been a communications breakdown within LL that has lead to an incorrect Support message being sent out. As a result of this error, which occurred this morning, Commerce Team Linden posted the following assurance at the time:
“We are so sorry for this response. We are reaching out to you directly to help you with this issue and are already working to make sure that everyone in support is aware that we will continue to support Magic Boxes until they are officially retired. Thank you for bringing this to our attention”. [My emphasis]
So, Magic Boxes are still supported, and will continue to be supported, and issues with them should continue to be reported.
Update 20:15BST:According to current feedback, the scheduled SLM maintenance did not address this issue, although there was no guarantee it would. That the maintenance was initially rescheduled to Monday April 2ndmight be indicative that a resolution is in development.
There appears to be a major error with the SL Marketplace.
A JIRA (WEB-4587) has been raised on the issue, which is being looked into as a “top priority” by Linden Lab. If you are merchant with SLM listings, and have not been aware of this issue, it would be advisable for you to check your store listings.
Key issues include:
Listings on Marketplace stores do not match the actual items
Incorrect merchant attribution (products from Merchant X listed as belonging to Merchant Y, despite appearing in Merchant X’s store)
Products from one merchant appearing in stores belonging to other merchants
Items incorrectly priced
Incorrect ratings assigned to products (G-rated items appearing as Adult, etc.).
Further, it should be noted that:
It appears that even if your own listing do not appear impacted, it is possible your products are still being listed in other stores
Items previously correctly impacted can be impacted as a result of updates
The problem is not limited to Direct Delivery items, but is affecting both items migrated to DD and items still in Magic Boxes
Update March 29th: Updates on payment problems (see below)
Update:As noted in the comments, it appears the Linux version of Niran’s Viewer is capable of running the Merchant’s Outbox without incident. If you’re a Linux user and keen to make the migration / stuck part-way through migrating, you might try it.
Issues are starting to be reported in relation to Direct Delivery.
Outbox Initialisation Failure
People are reporting that the Merchant Outbox is failing to initialise. The issue seems to be most closely related to Linux, but has also been reported for Windows and Mac, and JIRAs for all three have been created:
Outbox initialisation fails on Linux (JIRA VWR-28629)
Outbox initialisation fails on Windows (JIRA VWR-28630)
Outbox initialisation fails on Mac (JIRA VWR-28631) builds
I’ve used the Outbox on all current Viewers with the capability and using Windows 7 32-bit, with no issues. These currently are: the latest SL Viewer (3.3.0.251182), Firestorm 4.0.1, Niran’s Viewer (1.30+), and Zen viewer 3.3.2.0. However, I may have escaped issues for two reasons:
I am logged-in to my Merchant’s page on SL Marketplace
I use the English language version of the Viewers.
Linden Lab are still investigating problems, but if you are experiencing issues with the Outbox on Windows or Mac OS, you might try the following:
Ensure you are logged-in to your Merchant home page / manage listing page prior to trying to run the Outbox in the Viewer
Lance Corrimal suggests the Linux problem is related to an OpenSSL issue with Linux builds of the Viewer (which has impacted Linux users’ ability to upload snapshots to their profile feed).
If you do have repeated issues with trying to get the Merchant Outbox to work, and the suggested solutions above do not work, please visit the relevant operating system JIRA and logged your error, giving full details of your Viewer environment (available by option HELP->ABOUT (Viewer name), and copying the information given there.
Payment System Failures – Updated
There are also reports that some merchants who converted to Direct Delivery are experiencing issues over payment for transactions. While a similar issue existed prior to DD going live (transactions stalled at “being delivered”), the issue appears to be more noticeable now, with some merchants reporting that converting back to Magic Boxes seems to clear their particular problem.
A number of JIRAs are open on issues at present:
WEB-4441: Delivery status frozen with Being Delivered Status on marketplace transaction. 1399L lost and item never delivered (merged with WEB-4559, previously referred to in this article, now closed)
WEB-4580: Direct Delivery Issue – Item named with unicode characters causes order/payment system to fail
WEB-4596: Direct Delivery is hanging in “Being Delivered” rather than forwarding funds to Merchants even when the item has been paid for and received by the Customer. This is for NON-UNICODE Listings
So, Direct Delivery launched yesterday. I’ve been playing with it since then, and here’s some feedback and updates on what is being reported via the Merchant’s forum.
My Experience
Moving Goods to Folders
This was the most time-consuming task, mainly as I used it to re-order my business folders so that they can now be directly dragged-and dropped with each update. Inventory did get somewhat inflated, as I opted to move the originals of folders uploaded to SLM to my inventory and keep them as “master” copies into which I could drop updates, etc., ready for future uploads.
Uploading via the Merchant’s Outbox
Uploading a folder via Niran’s Viewer
Worked a treat using the SL Viewer, Firestorm and Niran’s Viewer.
Folders dropped into the Merchant Outbox folder would be duly processed and sent without incident, the only slight delay being the time required for the Outbox to initialise itself.
Once uploaded, those items set with the same original name as items in my listings auto-updated as anticipated, and those requiring a manual update (I took the opportunity to do some updating!) required around 4-5 seconds apiece to re-associate (although such was the demand on the Marketplace yesterday, this did at times take longer, prompting me to leave cutting-over much of my stock until this morning, UK time).
I will confess to keeping the old Magic Box items on file at the SLM end, under unassociated items, just in case! (I’m lucky, my total stock is just under 50 items.) I also started cautiously, a folder at a time, but confidence quickly grew that the system wasn’t about to do anything nasty and bumped over around 6 folders at a time.
Concerns with Direct Delivery
A number of concerns / issues have been raised via the Merchant’s forum.
Changes Mean Manual Association
An irritant with the new system is that if changes are made to the contents of a folder – such as the addition of new items, changes to a notecard, etc., – the folder, when uploaded to SLM is not automatically associated with an existing listing even if it retains the same name as an existing folder.
This means every time a change is made to the contents of a folder already listed on SLM, the merchant must manually associate the folder with the required listing and delete the older version of the folder when it appears in Unassociated Items – something that could add considerable time to the process when making multiple updates.
Deleting Unassociated Items
Some people have been reporting problems when deleting unassociated items. This can actually be time-consuming if done on an individual basis – and some merchants may find they need to remove some as they go, as there appears to be a limit of 100 unassociated items per merchant, it could get a little tedious. Sera Lok therefore suggests a solution in the forum.
The ANS Issue
At the time of launch, the Automated Notification System has not been enabled for Direct Delivery, and Linden Lab have only committed to turning this feature on in the “next couple of weeks”. Given the number of merchants who depend on ANS for records-keeping, and the fact the LL were repeatedly asked not to roll-out Direct Delivery whouth ANS being enabled for it, this is causing understandable reluctance with some in converting to Direct Delivery.
Destination Folder not Reported
As part of the launch documentation for Direct Delivery, it was stated that: “The Delivery folder will appear on the order and in all email notifications to the recipient.”
The promised format for deliveries recorded on people’s Marketplace account histories
However, the functionality does not appear to have been rolled-out with Direct Delivery. Neither merchants nor recipients are informed of the purchase destination either in their account histories or in any associated e-mails relating to the transaction.
As deliveries are currently displayed in a person’s Marketplace account history (Marketplace->MyMarketplace->My Account->Order History
While this is not a show-stopper, a JIRA has been raised on the matter.
Recipients do, however, get an in-world notification that goods have been delivered to their Received Items panel / folder if they are logged-in to SL / when they log-in to SL (assuming they review all stored notifications!).
Viewer Support
At the time of my original report on Direct Delivery, all Viewers on my Viewer Round-up list supported Received Items, as did much older (pre-mesh) versions of Viewers I tested (Imprudence, Singularity, Astra).
The Merchant Outbox situation is slightly different. As it stands at the time of writing this piece, this is the situation with the Viewers I’ve checked:
Viewers supporting Merchant Outbox functionality: the SL Viewer, Firestorm 4.0.1, Nirans (currently 1.30, but has supported it for a while)
Catznip is working on an update to be released shortly (RL interrupted the schedule)
Cool Viewer, Dolphin, Exodus, Phoenix, RLV, Singularity and Zen all appear to require updates in order to display the Outbox.
If your preferred Viewer does not currently support Outbox functionality, the best thing is to keep an eye on the Viewer’s blog pages for word of any update.
Overall Response
The overall response has been muted. While concern over ANS may be holding merchants back from any migration and the manual association requirement notwithstanding, this has been one of SL’s quieter roll-outs. Certainly, there do not seem to have been any major SNAFUs or problems – but then, many merchants may still be holding off on conversions.
Personal Feedback
I resisted giving feedback in my main piece on Direct Delivery, as I wanted to keep it as factual as possible (and am still updating it to reflect the current situation). However, my core feedback after using the system is:
The Good
The migration process via a suitable Viewer is pretty seamless for the most part. Automated association worked fine where folder names were the same as item names; manual association was a couple of additional steps, but not overly time-consuming if updates are taken in batches
Delivery works to any Viewer, regardless of base code (V3 or V1 style) – Received Items appears either as a panel in your Inventory floater (V3-based Viewers) or as a folder (V1-style Viewers)
No hiccups were encountered in sending goods as gifts or with permissions ending up mangled
The Bad
No ANS. Given the manner in which merchants repeatedly campaigned for ANS to be active for Direct Delivery, the decision to roll-out without it is somewhat surprising. Should ANS support be delayed, one hopes LL will also delay the turning-off of Magic Box functionality to allow merchants time to migrate to DD without having to face an artificial time limit
Failure to auto-associate updated folders as a result of content changes. One can understand folders remaining unassociated following an actual change to the folder’s name, but leaving folders unassociated simply because contents have changed adds unnecessary overheads to the process of updating items.
Inara Pey: Living in a Modemworld 