We are currently using Unity 6.3.9f, and have been experiencing these very weird editor errors where it complains about IMDB database. Usually, there are a few error messages, and it always happens at least once a day. When we close and open Unity, the error goes away, but it always returns. We have not encountered this issue before using older Unity versions.
This affects our workflow as we usually have Error Pause enabled and we would always have to restart Unity once this happens, else it will slow down.
Some examples of the error message received are:
Cannot open lmdb database Library/Search/98957a664bd18c47a3e41b2a0189ef53.SearchIndexArtifactImporter.196609.b.index because another process has a lock on it
If it were IMDB, it would definitely be strange But this is actually an LMDB error, coming from the new Advanced Search backend that landed in 6.3. I will bring this back to the team so we can diagnose and fix it.
Hi! Can you validate if you are using custom indexes that would be still present in your project? Or if you are using the SearchIndexer API directly to create your own indexers? The first error you mentioned is the main Search Index Database, but those mentioned in the image are not. The fact that there is the error “MDB_TLS_FULL” would suggest there are many LMDB map files being opened at the same time, i.e. too many Search Databases. Thanks for reporting.
As far as I know, we are not using custom indexes or using the SearchIndexer API in any way. The closest we have used to search for assets in our project is AssetDatabase and System.IO (eg. directory path etc).
However after searching through the codebase, I realized in the ‘‘com.unity.render-pipelines.universal’’ package we are using for the renderpipeline (it is custom, but should be the same as the default provided with some pass edits), there are some places in the code that uses Search.SearchService that might be related.
An example would be as below:
if (isDeepSearchEnabled != Search.SearchService.IsDeepIndexingEnabled() ||
isPackageIndexingEnabled != Search.SearchService.IsPackageIndexingEnabled())
{
// Rollback the index settings, and call the callback to notify that the initialization is done
Search.SearchService.ChangeIndexingSettings(
deepIndexing: isDeepSearchEnabled,
packageIndexing: isPackageIndexingEnabled,
InitializationFinish);
}
else ...
Similar codes can be found in scripts like SearchServiceUtils.cs and RenderPipelineConvertersEditor.cs in the Editor folder of the package.
Will try to take more screenshots and see if the errors would direct to these scripts the next time we encounter this issue again. Hope the information provided helps!
Thanks for that information! We will investigate the issue with the AI package. In the meantime, could you check if the content of the library folder is locked when you get these errors? Or do you have multiple Unity instances running on the same project?
try deleting the Library/Search folder with the project closed to wipe it clean (that would also confirm whether something’s locked, in that case: reboot, delete again)
exclude antivirus from “live” scanning the project folder (and anything else that might frequently scan/monitor files)
Project Settings > Editor > Parallel Import try disabling that - just a hunch, if the errors still appear: re-enable again
No no, he was merely moved into a package and abandoned.
Hello! Very sorry for the late reply, been a busy period.
I have tried the steps that you have mentioned:
I closed the project and deleted the Library/Search folder, and the folder deletes without any issues. I tried rebooting and delete again, still get the error
Currently, the devices we are working with only has Windows Defender, and scans are not run all the time
I have tried enabling and disabling the ‘Parallel Import’ setting, but still get the error in both cases
Our team decided that since we are not using the AI.Toolkit libraries, we removed them from the project. Since then, we have not been getting anymore of the mentioned LMDB issues anymore. Though the actual issue is not solved, this is a good enough for us.