Pipeline still accessing PSIStore after leaving call (PSIBot)

[HannahBruch]

I've been using PSIbot to join a teams call and record meeting audio and video to a PsiStore. After the call has been ended (but while the bot is still running), I need to do things with the PsiStores created. However, even after the call has ended (and the pipeline seemingly disposed of) the stores are still being accessed by the program, and any attempt to access the file ends up throwing an IOException with message "The process cannot access the file "....Catalog_000000.psi" because it is being used by another process." It's also very easy to see that the files are being accessed when the bot isn't in a call with Process Explorer, which also indicates that it moves on from the previous store when the bot joins a new call. What can I do to ensure the file isn't being accessed by the stream any more after leaving the call? I've tried:

• Disposing of the exporter in CallHandler's PipelineCompleted event handler (throws a NullReferenceException)
• Making exporter a property of CallHandler, and disposing of it in CallHandler's dispose method (also throws a NullReferenceException)

[sandrist]

Are you shutting down the pipeline at the end of each call, or does that keep running? Does the pipeline shutdown cleanly, or is an exception being swallowed somewhere? I would suggest setting some breakpoints and stepping through that shutdown process to be sure. If the pipeline is able to shutdown and be disposed cleanly, it should be able to properly close any stores that are attached to it. And then you can create a new pipeline for a new call and attach a new store to that.

I would not recommend trying to dispose exporters manually yourself. The pipeline shutdown process should take care of it.

Another thing you can check is if the folder with the psi store files has a ".live" file in it, indicating that the pipeline never closed it properly (and psi still thinks it is a live store still being collected). Opening a broken store like this in PsiStudio will automatically repair it, so that's another thing you could try experimenting with.