[sldev] Inventory Predicament

[Timeless Prototype]

Wow, very cool.

My Timeless Prototype avatar is no longer usable, I have missing assets 
and whenever a friend comes online (regardless of notify option) it 
locks up the SL viewer for about 5 seconds (ie. absolutely nothing moves 
on the screen, not even the mouse). With the number of friends I have 
it's impossible to do anything with this fault. All other applications 
are fine, even SL voice continues happily whilst this happens.

I too am on a basic account with no phone support. I've managed to log 
on and do some very basic maintenance, even though extremely painful, 
but I'm afraid it's the end of SL for me unless this can get fixed. The 
problem only started with the latest Windlight and RC viewers. The 
"stable" viewer has other issues for me, such as the huge delay whilst 
logging on, resulting in a nice faceplant and failure to load my avatar. 
My alts log on just fine, no issues whatsoever with those.

I refuse to buy a sim just so I can report a fault with my one avatar's 
inventory via phone. Just like you, Jira has proved absolutely useless 
to me for reporting a bug that relates only to my situation.

- Timeless

Brandon Lockaby wrote:
> Inventory Predicament
>
> It started a few months ago...  After letting the ~13,500 items of my 
> inventory fetch, opening the texture picker or resident picker, or 
> opening a second inventory window, would cause my viewer to freeze.  
> Everything was fine until a certain amount of inventory fetching was 
> done.  Also, if I didn't clear my cache before attempting to log in 
> again, the freeze would happen during the login process.  So I got in 
> the habit of hitting the 'clear cache' button every time after logging 
> in, to make sure I didn't have to run the viewer twice next time I 
> wanted to log in.  And I got in the habit of not being able to use the 
> texture picker and resident picker.
>
> Being a lowly Basic member, I don't have access to support, so I filed 
> a JIRA issue, but of course the issue was unique to me, so I 
> eventually marked it "more information needed" and closed it.
>
> In connection with a viewer exploit involving inventory transfers, I 
> had the opportunity of a generous Linden taking a look at my 
> inventory, and he removed some troublesome top-level folders.  But the 
> problems never went away.
>
> Several months passed :O
>
> Tonight I had the opportunity to try the Second Inventory viewer.  It 
> turned out to be alot more featured than I expected.  But when I 
> loaded my 'Objects' folder, it threw about 100 dialogs saying I had a 
> bad reference to "ce5da405-26d2-4004-a01c-56a3ced4d68a" or it was not 
> a folder.
>
> Now, I had a UUID.
>
> In the Second Life viewer's cache folder, there's a <your agent 
> key>.gz file with a text file inside for caching your inventory.  I 
> decided to search the file for that UUID and see if I could figure out 
> what was up.  The first occurrence was:
>
>     inv_category    0
>     {
>         cat_id    ce5da405-26d2-4004-a01c-56a3ced4d68a
>         parent_id    d2ed5dee-3801-46f6-8d8a-1f01133b2673
>         type    category
>         pref_type    object
>         name    Objects|
>         owner_id    97b817dc-5dd3-498a-bdd2-5644d0aa8fb4
>         version    11395
>     }
>
> That's my Objects folder.  And indeed, all of the objects inside had 
> it as their parent_id.  But since the Second Life viewer and Second 
> Inventory were, in fact, able to show all the items in my Objects 
> folder, that didn't make sense of anything to me.  I kept looking, and 
> eventually found this item:
>
>     inv_item    0
>     {
>         item_id    ce5da405-26d2-4004-a01c-56a3ced4d68a
>         parent_id    ce5da405-26d2-4004-a01c-56a3ced4d68a
>     permissions 0
>     {
>         base_mask    7fffffff
>         owner_mask    7fffffff
>         group_mask    00000000
>         everyone_mask    00000000
>         next_owner_mask    00082000
>         creator_id    97b817dc-5dd3-498a-bdd2-5644d0aa8fb4
>         owner_id    97b817dc-5dd3-498a-bdd2-5644d0aa8fb4
>         last_owner_id    00000000-0000-0000-0000-000000000000
>         group_id    00000000-0000-0000-0000-000000000000
>     }
>         asset_id    00000000-0000-0000-0000-000000000000
>         type    object
>         inv_type    object
>         flags    00000000
>     sale_info    0
>     {
>         sale_type    not
>         sale_price    10
>     }
>         name    Object|
>         desc    (No Description)|
>         creation_date    1195342436
>     }
>
> Amazing, it has the same UUID as the folder it's in, and must be the 
> problem item.  So I loaded up the Second Life viewer, fetched my 
> inventory, and did a search for "Object."
>
> Unfortunately, I couldn't see the object.
>
> So, at this point, being an overenthusiastic slproxy user, I start 
> thinking maybe I can figure out how to delete an inventory item by 
> injecting a packet, and hopefully it doesn't work by UUID alone.  I 
> look through http://wiki.secondlife.com/wiki/Category:Messages for 
> messages having to do with inventory, and log them while doing some 
> tests with moving and deleting inventory items.
>
> I find I have two options:
>
> RemoveInventoryItem
> http://wiki.secondlife.com/wiki/RemoveInventoryItem
> Purge a single inventory item, given its UUID.
>
> MoveInventoryItem
> http://wiki.secondlife.com/wiki/MoveInventoryItem
> Move an inventory item, given its UUID, to another folder, given its 
> UUID, with an optional new name.
>
> Since RemoveInventoryItem takes only a UUID, I'm too nervous to use it 
> right away with a UUID that represents both the problem item and my 
> Objects folder, even though there is a separate message, 
> RemoveInventoryFolder, for purging a folder.  I mean, 
> behind-the-scenes, what if the database operation just uses the UUID 
> alone, and purges my Objects folder >_<  And obviously, the UUID is 
> enough to cause problems with the viewer.
>
> So I use slproxy to send a MoveInventoryItem packet condemning 
> ce5da405-26d2-4004-a01c-56a3ced4d68a to my 'Trash' folder.
>
> [4:04]  Analyst: failed to inject fix: Object reference not set to an 
> instance of an object.
>
> I guess it won't let me inject the packet without it mentioning the 
> NewName parameter, and I'm not sure if using an empty string will have 
> the desired effect, so I add NewName = TROUBLE to the packet and 
> inject again.
>
> No feedback... No item visibly in my Trash...
>
> I right-click my Trash and empty it, and verify that the viewer sent a 
> PurgeInventoryDescendents packet, for purging its contents.  God, I 
> hope I did it!
>
> Clicked the clear cache button, logged out, logged back in, and let my 
> inventory fetch.  I am relieved to see I still have an Objects folder, 
> with objects in it.  I rez some of them while waiting for the fetching 
> to be over.
>
> The fetching is over.  I create an object and click the Texture box... 
> the viewer stops...
>
> But after about five seconds... IT WORKS!!  THE TEXTURE PICKER!!  How 
> I'd missed it ;__;  I close and open the texture picker again and 
> again!  I use New Window on my inventory... it takes about 15 seconds, 
> but it worked!  I open the parcel options and click Add next to the 
> ban list... after six seconds, it worked!!
>
> Finally, I logged out without clicking 'clear cache' first, and log 
> back in.  Z-O-M-G, I am logged in and I already have everything 
> fetched.  I am hugging slproxy.
>
> So my question is, how did this happen? :D
>
> Can we fix the bug in the viewer that made this SUCH a problem?
>
> And is there any danger of my Objects folder being garbage-collected, 
> now? ;__;
> ------------------------------------------------------------------------
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>