Cool VL Viewer forum

Hi Henri,

i had some issues with restoring the outfit on login a few times now. (see Logs, have a 4th log too, but can only upload 3 files...)
The frequency seems to have increased a bit over time, but is so rare i cannot reproduce it easily.

I frequently move between two computers, laptop and desktop that do not share a file system. The failure often starts when i changed outfits on one system and then switch to the other, but not always, most of the time it just works. Sometimes it happens, even if i do not change outfits at all.

Usually it is the same items missing:
- Most old layers (skin, shape, eyes, tattoos, foot shape, scalp)
- Some Mesh attachments (nearly always the same items are missing actually, but with some variations whats missing additionally)

The annoying one why i filed this today is, that it failed repeatedly in a short timeframe:

1. Login on Laptop, outfit is trashed, rewear outfit, log off
2. Login on Desktop a few hours later, outfit is trashed again, rewear slightly different outfit, log off
3. Login on Laptop, outfit is trashed once again, rewear, log off
4. Login on Laptop, outfit is still broken, repair again...

Maybe you can give a hint what might be happening here?

Log #4.

Well, logs 1 and 2 are "normal" and did lead to a full outfit restoration.

Log 3 shows a lot of warnings about invalid cached inventory categories (folders), so it is possible that this caused a (local) corruption of the outfit, if one of the invalidated items was part of it... Normally, the local inventory should however get updated, provided you re-wear the outfit or swap it for another.

Log 4 shows an outfit restoration failure (no reply from server, apparently, perhaps because of a duplicated or invalid link in the COF, server side)...

Note that I just tried on 4 different computers and 3 different avatars, and could not encounter any such issue here (and since I did not touch this part of the code in months, it is unlikely to be a "new" bug).

My advice would be to enable the "Appearance" and "COF" debug tags (from the Advanced menu) just before login, to gather more info in the logs about what could be happening.

To solve the issue, you could also try and wipe out the cache folder in each of your computers, before logging in and see if it makes any difference.

Thanks.

I'll see if additional logging shows something.

But as said, it happens pretty rarely. Usually only around 1-2/month or so. So i was surprised it happend 4 times in two days recently.

Likely an inventory cache corruption on one of your PCs, which caused some weird issue (bad link, maybe) in the COF, and thus caused issues when logging in with another PC...

I'm still encountering this, infrequently, even if on the same computer. Another friend also encounters the same issue (but she has crashes due to lack of RAM and overheating anyway, so all bets are off).
I guess it is some form of inventory cache corruption,

There are some typical odd common behaviours, for me every time it happens.
Like it is always pretty similar things that go missing. I placed them in the same folder (no links, copies).
- Skin, Shape, Tattoos, Hairbase, Shoebase, Physics
- Certain Mesh items (INM, one of my two spankers, Collar, MamaAlpa HUD)
- If i wear mesh gloves, most of the time only one is gone (the right one...), the other is still there
- My shoes / boots are usually gone

All the rest, mesh body, clothes, etc. usually survive without harm. It doesn't matter if i changed clothes or not. There seems to be no correlation to "just worn" or "worn all the time".

I think there might be some correlation to teleporting home and logging off a few seconds after that. Could it be that there is some race condition on shutdown that corrupts the file? Or is this mainly a server side issue?

I'll keep looking for more clues and maybe logging to see if i can catch the corruption when it happens, but no luck yet.



And then it fails with a COF timeout later.


In a succesful case, it loads 8840 categories.

Sadly, there are server-side issues behind this: the viewer is just doing with what it receives from the server at login (when the full inventory tree is transmitted in the login response message).

When the viewer inventory tree cache does not match with the server, it is resynced with the latter, and when the latter is bogus, the viewer ends up with bogus data...

I'm afraid there is nothing I can do on my side.

However, I personally do not see this happening with my avatars, and your supposition about a race when logging out while a full rebake did not complete is indeed a possible cause (*). That's why I implemented the "red shirt" icon in the status bar, to reflect the baking status (red when a baking is in progress): you should never log off or teleport while this icon is red, and you should instead wait for the rebake to finish, so to be sure that both the viewer and the server do agree with what links are present in your Current Outfit folder...
I suppose I could implement a TP and log off forced-delay when baking is in progress, but then there would be issues when you try and log off because your network is down or flacky, or when the server went kaput...

You could also use the local outfit file (outfit.xml) method to restore outfits (I created it for this very purpose: to ensure that the viewer is the authoritative pole for what the avatar is wearing on login): in "Advanced" -> "Character" menu, disable "Restore outfit from COF", and do read the alert/caveats that will pop up, since it changes how the viewer behaves on login and may surprise you when you log in from another computer (but this also brings a nice new feature, when wearing NSFW outfits at home and wanting to log in at work ).

---

(*) Please note that due to another server bug (bogus un-parenting of the agent avatar attachments on sim changes) for which I had to implement a workaround (Advanced -> Network -> Ignore bogus kill-attachment messages), a rebake may be needed (to resync the inventory server which sadly also receives the bogus un-parenting/detach event from the departure sim server) after a sim change (sim border crossing or TP alike): if you log off after a TP and before the viewer could rebake (when needed: this is not always the case), then you risk seeing the COF lacking some inventory links (or storing broken links) to attachments on relog, causing such a mismatch between the inventory server data and the cached inventory data... My outfit.xml-based outfit restoration method would not be impacted either by this kind of issue.

Thanks for the hints, about what could go wrong. I will keep an eye open for those indicators you mentioned.

The whole client-server protocol seems to be too fragile, but well, nearly 20 year old code. I have written my own share of network replication/syncing code to know how hard it is to make things really robust. Seems SL didn't make invalid COF state unrepresentable, which would have been smart.

Its still rare enough to not be too annoying. I usually take it as a reason to change my outfit, so the harm is minor. It is just one of the "This shouldn't happen" bugs that are annoying on an intellectual level, like an assert triggering because some assumption was wrong.

Actually, I came up with a better algorithm for the loadSkeleton() method, which now force-fetches the categories that were found to have broken links; this might be sufficient to get the COF to resync before the viewer gives up trying and restoring the outfit from it...

I'm giving you a link to the test viewer in PM: let me know if you still can reproduce the same issue or not with it.

I tried a few dozened relogs & tp's and changes to see if i could get the patched viewer to break, but it worked each time.
But as said, the issue was rare, so this is no confirmation its really gone, i can probably tell after a month or two.

What i did notice was, that it seemed to be faster to restore the outfit, e.g. the "Outfit restored" popup came up faster than before. But no measurements if thats true. It felt faster at least.