Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2024-03-28 22:08:40



Reply to topic  [ 24 posts ]  Go to page Previous  1, 2, 3  Next
Attachments not kept after log out / log in sequence 
Author Message

Joined: 2010-04-07 08:23:18
Posts: 210
Reply with quote
Henri Beauchamp wrote:
[...] and you are reporting here an issue that would deal with something that has been implemented for now over a year and that never caused any problem for any one else during all this time [...]

I guess it's time for me to chime in, then. The way Cool is handling multiple attachments on single attachment points hasn't worked well for me from day one, I just never bothered enough to bring it up. Quite frequently I do have issues there -- Typically only one of, say two, attachments will reattach upon relog. Occasionally things work as designed, however.

This is on Linux, mind you. And yes, my inventory has crept up to around 28000 or so items by now, so I suppose it would qualify as "large". And another observation: my inventory cache never seems to be up to date upon relog, typically it needs to add a couple of hundred items right there and then -- and no, this is not related to previous crashes. So it seems that the update of the inventory cache at/around termination might indeed be the culprit here.

So what Erika is reporting isn't that far-fetched at all.

Love,
Lia


2011-12-16 18:52:17
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
I've got 12700 items in my inventory, so it compare with Erika's, and *never ever* observed that issue... Of course, when SL's asset server is overloaded (it happens almost every day roughly at the same time when both Americans and Europeans come on line (mid-day US/evening EU), some attachments *might* fail to rez at all, but it's not the viewer's fault...

If your inventory keeps loading at each login, it's a clear sign that the cache file is somehow corrupted: log off, wipe it off, relog, let your inventory load fully, log off again (to ensure the cached inventory list is saved), then relog: from now on, there should not be any loading on relog, but for the items that you could have received while offline.
Also, it's normal that things get out of sync if you log in with a different viewer, then relog with the Cool VL Viewer (and vice versa).


2011-12-16 19:36:15
Profile WWW

Joined: 2011-12-13 14:11:38
Posts: 186
Reply with quote
Henri Beauchamp wrote:
I've got 12700 items in my inventory, so it compare with Erika's, and *never ever* observed that issue... Of course, when SL's asset server is overloaded (it happens almost every day roughly at the same time when both Americans and Europeans come on line (mid-day US/evening EU), some attachments *might* fail to rez at all, but it's not the viewer's fault...

I did have the problem you describe a few times, but not with CVLV yet. And this problem triggers a warning message, doesn't it? Here, I have nothing at all, just attachments that were there when I logged out and that are no more there when I log back in. And that always happens, each time I log in, and almost always with the same attachments.
And I'm sorry, but I still fail to see how claiming an item isn't in my inventory when it is can be build-related. I could have understood a problem of cache corruption, but I wiped it out completely. Didn't really see how this could be related to the settings, but I did wipe them out completely anyway, and it still happens. I made sure my inventory was completely in my cache, and now it is: I never see it loading when I'm logging back in. And still, the attachments are missing. What can I say? Maybe I am using multiple attachments as no-one ever did, or someone already had the problem and didn't say it.
I'll try to find a way to reproduce the problem without the exact same attachments I'm using, since they are things I bought. If i can reproduce it, I'll post what I did here, just to know if the problem is actually related to my setup or not…


2011-12-16 21:20:11
Profile

Joined: 2010-04-07 08:23:18
Posts: 210
Reply with quote
Henri Beauchamp wrote:
[...] log off, wipe it off, relog, let your inventory load fully, log off again (to ensure the cached inventory list is saved), then relog: from now on, there should not be any loading on relog, but for the items that you could have received while offline.

Been there, done that -- many times in fact, for a variety of reasons (usually I clear cache the hard way whenever I see a cached sculpt texture has gone bad, as there seems to be no way out of that issue). Inventory is cached, but the cache state at logoff does not seem to be 100% up to date. As I said, we're talking a couple of hundred items that are loaded after logon. Obviously I don't get that many while I'm off.
Henri Beauchamp wrote:
Also, it's normal that things get out of sync if you log in with a different viewer, then relog with the Cool VL Viewer (and vice versa).
Obviously. I can understand you stressing things like that over and over again, but giving a bit of credit to people now and then might be a good idea. The (few) times I have actually used other viewers, I always moved my ~/.secondlife folder first. 'Nuff said.

Love,
Lia


2011-12-17 09:07:37
Profile

Joined: 2010-04-07 08:23:18
Posts: 210
Reply with quote
ErikaThorkveld wrote:
Maybe I am using multiple attachments as no-one ever did, or someone already had the problem and didn't say it.
I'll try to find a way to reproduce the problem without the exact same attachments I'm using, since they are things I bought. If i can reproduce it, I'll post what I did here, just to know if the problem is actually related to my setup or not…
Well, we're two now, and maybe others will come forward eventually. I pushed the issue aside in the past, because for some reason it wasn't upsetting me enough to bother, but I'll see if I can provide some more input as well. Considering the issue happens on at least two platforms, It is very likely to be a general issue.

Love,
Lia


2011-12-17 09:13:31
Profile

Joined: 2010-04-07 08:23:18
Posts: 210
Reply with quote
Ok, I decided to have a look at the inventory stuff when logging on, and this line in the log most likely shows what's going on:

loadSkeleton: Attempted to add 578 cached link items without baseobj present. The corresponding categories were invalidated.

It then proceeds to list the folders it's discarding:

loadSkeleton: Invalidating category name: Bimbo doll UUID: 09487a0b-fc54-74ff-60cf-ae32ccf2ff3f due to invalid descendents cache

(And so on ...)

All of these do contain inventory links. And no, not broken ones. Not even one.

Since an entire folder that contains an item that should get reattached is discarded from inventory this way, the consequence is of course:

checkAttachments: e594ca93-3d72-4fcb-565b-df59a41bf468 not found in inventory, could not reattach.

So Erika, could you check if the issue works the same for you, i.e. is possibly related to folders containing inventory links?

Love,
Lia


2011-12-18 12:43:27
Profile

Joined: 2011-12-13 14:11:38
Posts: 186
Reply with quote
Thanks a lot for the time you're spending on this, Lia. Unfortunately, what you describe doesn't seem to be the problem for me. I do have some 'loadSkeleton: Invalidating category name…' messages in my log from time to time, but they don't seem to be related to the attachments I'm losing. And there are cases where I do lose the attachments, but there's no such 'loadSkeleton' message in the log, so I guess it's not related, at least not for the problem I have.

I did find a way to reproduce a problem looking a lot like the one I'm having though. Here is what I'm doing:
  • I'm stripping my av of everything except my shape, skin, eyes and hairbase, just to be sure there's nothing interfering;
  • I've created a prim - for me it's a sphere I made transparent, but I guess it isn't really important - that I've copied twice with different names;
  • I attach both copies to the same attachment point. The first time, I'm using the 'Attach to' menu on the attachment point I've chosen for both. The other times, I'm just doing an 'Add'. Tried with attaching to pelvis or spine, it did the same thing.
  • I open the preferences, go to the 'Network & Web' tab and click the 'Clear Disk Cache' button.
  • I log out of CVLV, then log back in.
After that, there's almost always one attachment missing on the 2. On the 4 times I did it, an attachment was missing 3 times, and the message 'WARNING: checkAttachments: … not found in inventory, could not reattach' appeared in the log. And of course, the object still was in my inventory, and reattaching it worked without problem.

Correct me if I'm wrong, but it should be working wether the attached prim is in the cache or not, right? In any case, it is quite weird that only one of the attachments is missing. I could have understood if both were missing, but why just one? So there really seems to be something weird happening between multiple attachments and the inventory cache…


2011-12-18 21:04:25
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Links are not attached neither listed in the attachments list: it's the linked object itself that is attached to the avatar and registered in the attachments.xml file. So even when cached links are discarded on login (this may happen when the cached link is listed before the linked item in the cache), it doesn't prevent the actual object to get reattached (it might however explain the reloading of Amalia's 578 links on login).

The "loadSkeleton: Invalidating category name: Bimbo doll UUID: 09487a0b-fc54-74ff-60cf-ae32ccf2ff3f due to invalid descendents cache" line however means that something is fishy in Amalia's inventory (somehow, the object failed to be properly cached and on reload, the viewer rejects the inadequate cache entry) and may indeed explain why the auto-reattach algorithm doesn't find the corresponding item.

As for why only one item per attachment point gets reattached, it's because of LL's stupidity... When you log in, the server sends to the viewer the UUIDs of the objects to reattach, but after LL modified the viewer to accept multiple attachments, they did not change the server side of the protocol and the server only remembers the last attached object for each joint. Instead of properly modifying the server side code, LL implemented the "Current Outfit" folder in the viewer and they use that (storing inventory links to worn objects/wearables in it) to decide what objects need to be reattached on relog. This latter method, beside crowding your inventory with a useless "Current Outfit" folder and its auto-created links, is alas incompatible with grids not implementing inventory links. This is why I'm not using it and instead using the xml file approach.

The Cool VL Viewer's auto-reattach algorithm kicks in only after the normal server-issued reattach orders are completed and the server-re-attached objects are fully rezzed, so it theoretically can't fail (the inventory should be fully loaded already). Apparently, the theory fails short in some "corrupted" inventory cases that I alas cannot reproduce with any of my avatars.

I modified the algorithm to make it more robust and so that it retries later when encountering "missing" inventory items instead of giving up immediately on them. However, there is a limit to the retries and if the inventory takes too long to refresh it might still give up after the (now configurable) maximum auto-reattach delay is reached...


2011-12-18 22:01:40
Profile WWW

Joined: 2010-04-07 08:23:18
Posts: 210
Reply with quote
Hi Henri, hello everyone!

Henri Beauchamp wrote:
Links are not attached neither listed in the attachments list: it's the linked object itself that is attached to the avatar and registered in the attachments.xml file. So even when cached links are discarded on login (this may happen when the cached link is listed before the linked item in the cache), it doesn't prevent the actual object to get reattached (it might however explain the reloading of Amalia's 578 links on login).
Ah, but here is the Catch-22: the links are discarded, probably for the reason you mentioned above; this in turn invalidates the folders containing them, scheduling them for reload (and yes, all the folders triggering the loadSkeleton: Invalidating category name ... do contain links). While they are still discarded and reloading, the reattachment is then attempted, of an item located in one of the discarded folders or its subfolders -- with the obvious consequence that it cannot be found and producing the not found in inventory, could not reattach message.

This theory would explain at least my personal observations perfectly fine. Which of course does not mean there is some merit to it. But do you see that as a feasible chain of events, Henri?

Henri Beauchamp wrote:
I modified the algorithm to make it more robust and so that it retries later when encountering "missing" inventory items instead of giving up immediately on them. However, there is a limit to the retries and if the inventory takes too long to refresh it might still give up after the (now configurable) maximum auto-reattach delay is reached...
That may indeed provide some relief for the issue. Obviously I lack the proper insight, but should the aforementioned theory be reasonable, then the real fix would be to avoid the links in inventory being discarded in the first place, if at all possible, right?

Love,
Lia


2011-12-19 16:29:03
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Amalia Illios wrote:
.../... Obviously I lack the proper insight, but should the aforementioned theory be reasonable, then the real fix would be to avoid the links in inventory being discarded in the first place, if at all possible, right?
This would be true (and a proper fix to links caching is indeed due sometime), but this won't explain why:
ErikaThorkveld wrote:
Unfortunately, what you describe doesn't seem to be the problem for me. I do have some 'loadSkeleton: Invalidating category name…' messages in my log from time to time, but they don't seem to be related to the attachments I'm losing. And there are cases where I do lose the attachments, but there's no such 'loadSkeleton' message in the log, so I guess it's not related, at least not for the problem I have.
So, the robuster reattach algorithm is still needed and should hopefully prove a proper fix...


2011-12-19 23:45:29
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 24 posts ]  Go to page Previous  1, 2, 3  Next

Who is online

Users browsing this forum: No registered users and 25 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.