OpenSimWorld is the directory of 3D Virtual Worlds based on OpenSimulator and connected through the HyperGrid. Learn More
New Members
Elyion, Ed Valerik, Miyako, Tabata100, Gracieann, ValanaBell, Noahh, LisielleMyrt, DjMaxMatarazzo, DJSerenity, CeloeManio, Jon Lionheart, MaxMax, Palkovnikx, Cullen_Bohannon, MG_VAWD, 27535, TaliaStargarden, Edward10, Luna_SkyeLikes
Remember back about 7 months ago, when Pagane and I told you all that Firestorm viewer was messing up the asset databases? Many called us liars. We even found the text and I copied and pasted it directly from the firestorm website that says this is true... https://opensimworld.com/post/112006 You can see it all in that original post above ^ Well now the situation has gotten so bad that users are starting to notice. Grids are starting to fall. etc. etc. Pagane works in her own business. One of the unique things she did is make a cacheless implementation of opensimulator. It was because of this that she stumbled across this problem the instant she upgraded her viewer above 6.6.14 as any viewer above that number has had some commits made that alter the way the data is read/written from the database. Again, remember, please, that firestorm ADMITS this on their own site. So for those of you who listened to us, enjoy your grid. To those who did not listen to us, enjoy your rebuild.
Note: because of Paganes cacheless implementation, when she upgraded her viewer to 6.6.16 she instantly saw her database getting destroyed instantly on the screen in front of her. Repair database, go back to 6.6.14 everything works. ok so far so good. reinstall 6.6.16 - boom database destroyed again. Repeat these steps, this time install 6.6.17 same problem - boom database crashes instantly. This has continued happening all the way up to the 7.x series.
Maybe the firestorm people need a cacheless version of opensim like Pagane has so they can INSTANTLY see the damage being done rather than letting it build up stealthily in the cache for long periods, so they would know what is going on?
Note: because of Paganes cacheless implementation, when she upgraded her viewer to 6.6.16 she instantly saw her database getting destroyed instantly on the screen in front of her. Repair database, go back to 6.6.14 everything works. ok so far so good. reinstall 6.6.16 - boom database destroyed again. Repeat these steps, this time install 6.6.17 same problem - boom database crashes instantly. This has continued happening all the way up to the 7.x series.
Maybe the firestorm people need a cacheless version of opensim like Pagane has so they can INSTANTLY see the damage being done rather than letting it build up stealthily in the cache for long periods, so they would know what is going on?
Liked by: 
Comments
WARNING ABOUT MY CACHELESS SERVER EXPERIMENTS!
THIS IS NOT USABLE FOR ALL!
Maybe I should explain why without cache, what are the advantages and what are the problems:
1. If you have a large grid with more than 4-5 simultaneous visits - FORGET ABOUT DISABLING THE CACHE!!!
2. Disabling the cache is for SMALL PRIVATE servers that serve only you and a maximum of 2-3 users!!!
What do you gain?
SPEED!!! The server works only for you and does not waste time with the cache, which is pointless - 2-3 avatars and everything they carry are collected peacefully in the RAM memory. The cache would only slow it down.
Everything on your screen will load extremely quickly, because there are no other requests and the data is not blurred in the cache.
Restarting the server takes a maximum of 3-4 minutes. Backing up the SQL database can be done even without a restart.
What do you lose?
You will always have a SMALL PRIVATE server!
You will NEVER grow up!!!
You will immediately see the consequences of other people's losses or damage to resources. For example, visitors from OSGrid could not use many of their belongings, bodies and clothes when they visited me. Now it turned out that these things were damaged long ago, but they used them from the caches, but coming to me.... well, there is no cache...
like(2)
THIS IS NOT USABLE FOR ALL!
Maybe I should explain why without cache, what are the advantages and what are the problems:
1. If you have a large grid with more than 4-5 simultaneous visits - FORGET ABOUT DISABLING THE CACHE!!!
2. Disabling the cache is for SMALL PRIVATE servers that serve only you and a maximum of 2-3 users!!!
What do you gain?
SPEED!!! The server works only for you and does not waste time with the cache, which is pointless - 2-3 avatars and everything they carry are collected peacefully in the RAM memory. The cache would only slow it down.
Everything on your screen will load extremely quickly, because there are no other requests and the data is not blurred in the cache.
Restarting the server takes a maximum of 3-4 minutes. Backing up the SQL database can be done even without a restart.
What do you lose?
You will always have a SMALL PRIVATE server!
You will NEVER grow up!!!
You will immediately see the consequences of other people's losses or damage to resources. For example, visitors from OSGrid could not use many of their belongings, bodies and clothes when they visited me. Now it turned out that these things were damaged long ago, but they used them from the caches, but coming to me.... well, there is no cache...
Every bug and fix in Firestorm, DrewmGrid and Opensim is well documented. Seems from a blog post, that Firestorm had a "potential" for messing up assets. The only one I see was renaming a folder did not always work. But no loss of inventory as it was tweaked to fix the rename bug. See FIRE-33337. That is the last 'old' viewer some people use. I see no sign of any inventory issues other than minor stuff in 6.6.16.70339, such as bug from 2013 which caused some deleted items to become orphaned from the deleted inventory folders and thus invisible. However this brings back deleted inventory from 2013. Nothing in 6.6.14.69596, but before that, the prior version 6.6.8.68380 would sometimes make it appear as if inventory was missing due to cache corruption. But only if you cleared cache, shut it down and restarted immediately without a short wait for the background process to clear cache.
if there has been any inventory corruption by Firestorm, no devs have reported or fixed it.
like(1)
if there has been any inventory corruption by Firestorm, no devs have reported or fixed it.
Right, this bug is the one tearing down grids. See it all comes down to the way the new outfit icons are stored and the trouble with twibbles.
like(0)
This is SAME bug. Outfit icons is one of simptoms, broken links in RDBMS etc, etc all is because Firestorm use direct access to assets server and not inform opensim server whats changed and where.
Of course you may run behind clients and repair FS "flowers" in real time but......
Want to try? CLOSE port 8003 and.... new FS stop to work or change how work. WHY? He must use only port 8002.... But yes///" -1 * -1 = +1 "
like(0)
Of course you may run behind clients and repair FS "flowers" in real time but......
Want to try? CLOSE port 8003 and.... new FS stop to work or change how work. WHY? He must use only port 8002.... But yes///" -1 * -1 = +1 "
Your link to the patch https://opensimworld.com/post/117455 @Pagane is a different bug I think as that is for the outfit issues, not the asset issues.
like(1)
There is new patch for Firestorm bug: https://opensimworld.com/post/117455
I cannot understand why Firestorm bug is patched in server code but.... may be is somethin similar to simple equation "-1 * -1 = +1"
like(0)
I cannot understand why Firestorm bug is patched in server code but.... may be is somethin similar to simple equation "-1 * -1 = +1"
The Firestorm devs need constant feedback from the OpenSim community. They themselves won't notice anything.
Firestorm has 20 devs AFAIK. 19 of them are only in Second Life. Only one has an OpenSim account and is mostly in Second Life, too. Everyone daily-drives Firestorm for Second Life, but nobody daily-drives Firestorm for OpenSim. Testing of Firestorm against OpenSim is probably limited to bare-bone basics like whether it can log in at all in the first place.
It has actually happened at least once that a Firestorm dev who only knows Second Life has copy-pasted code from the official SL viewer over Firestorm code with specific lines for OpenSim, that the change was rolled out with a stable release, and that nobody in the dev team even knew that Firestorm malfunctioned in OpenSim until the community pointed it out.
Firestorm for Second Life is released after meticulous tests. Firestorm for OpenSim is released almost entirely untested.
The only way for the Firestorm devs to even know that something is wrong on the OpenSim side is by submitting well-documented bug reports on their JIRA: https://jira.firestormviewer.org
Make it as easy as possible for the devs to spot the bug without having to invest too much time into replicating it. Write up all steps to replicate the bug. Add the expected and desired result and the actual result. Add server and/or viewer logs if possible. Be as specific as you can. Remember that only maybe 1/50 of Firestorm's dev team uses OpenSim.
Of course, it'd be even better if Firestorm got more devs who actually daily-drive Firestorm for OpenSim and who cover a number of grids with it.
like(1)
Firestorm has 20 devs AFAIK. 19 of them are only in Second Life. Only one has an OpenSim account and is mostly in Second Life, too. Everyone daily-drives Firestorm for Second Life, but nobody daily-drives Firestorm for OpenSim. Testing of Firestorm against OpenSim is probably limited to bare-bone basics like whether it can log in at all in the first place.
It has actually happened at least once that a Firestorm dev who only knows Second Life has copy-pasted code from the official SL viewer over Firestorm code with specific lines for OpenSim, that the change was rolled out with a stable release, and that nobody in the dev team even knew that Firestorm malfunctioned in OpenSim until the community pointed it out.
Firestorm for Second Life is released after meticulous tests. Firestorm for OpenSim is released almost entirely untested.
The only way for the Firestorm devs to even know that something is wrong on the OpenSim side is by submitting well-documented bug reports on their JIRA: https://jira.firestormviewer.org
Make it as easy as possible for the devs to spot the bug without having to invest too much time into replicating it. Write up all steps to replicate the bug. Add the expected and desired result and the actual result. Add server and/or viewer logs if possible. Be as specific as you can. Remember that only maybe 1/50 of Firestorm's dev team uses OpenSim.
Of course, it'd be even better if Firestorm got more devs who actually daily-drive Firestorm for OpenSim and who cover a number of grids with it.
Answer:
1: "The current Firestorm release is built on Ubuntu 22.04 LTS. "....(Release from Apr 2022) Really i not know peoples who use ancient versions of Linux distro.
2: "Technical support provided by our team for any Linux distribution other than Ubuntu is “best effort.” We cannot promise resolution of issues reported for every distribution out there!".... Not know how to explain easy and respectfull but.... we is not beta testers and use Debian or RedHat.
3: "Wayland Users: Compatibility is NOT guaranteed – there is no native Wayland support at this time"..... I not know how they support Ubuntu 22.04 but not suport Wayland:) This is same M$ to say "we not suport C# ot NotePad"!
like(0)
1: "The current Firestorm release is built on Ubuntu 22.04 LTS. "....(Release from Apr 2022) Really i not know peoples who use ancient versions of Linux distro.
2: "Technical support provided by our team for any Linux distribution other than Ubuntu is “best effort.” We cannot promise resolution of issues reported for every distribution out there!".... Not know how to explain easy and respectfull but.... we is not beta testers and use Debian or RedHat.
3: "Wayland Users: Compatibility is NOT guaranteed – there is no native Wayland support at this time"..... I not know how they support Ubuntu 22.04 but not suport Wayland:) This is same M$ to say "we not suport C# ot NotePad"!
Ok yes, my mistake, I copied the wrong version numbers. Any case that might explain why I saw little corruption in my assets as I rarely used those versions in Osgrid as I was testing the 7.1.** beta versions to check the PBR. I was mystified that so many were having huge problems when I only experienced a few issues that I could have easily resolved in a day or two.
like(0)