I've had this occur a number of times (twice in a row yesterday) where if you receive new records while doing a long read-all, this exception crashes ObsCore.
So may need some further digging, but in the meantime, it won't crash here.
* Add event-based LogMonitor state changes to better handle batch reads
Pre-reading hackily used read-all to suppress notifications. But that broke some assumptions about what read-all meant. Furthermore, the Core UI told plugins about read-all rather than the log monitor telling them -- which is really what should be telling them.
To address these concerns, LogMonitor now provides an event that both the PluginCore and PluginEventHandler listens to or tracking logging state allowing more granular information about the activities of LogMonitor, including distinguishing between ReadAll and Pre-read batches. Plugins no longer need to track if LogMonitor is in batch-read mode or not -- PluginCore now provides it.
I've also converted all built-in plugins to use the new event-based system. The old system is marked deprecated and will go away once other known contributed plugins have converted to the new system.
* Change LogMonitorState enum to [Flags], drop 'None' state
As requested, and did associated simplifications and cleanup that followed.
* WIP: initial commit for observatory herald
* Plugin error handling refactor
* make error window non-modal
* tidy up plugin error handling
* first pass for basic herald functionality
* corrections for linux env
* Use FNV hash directly instead of managing through dictionary/index file
* resolve audio queuing issue, switch to personal NetCoreAudio fork
* merge cleanup
* add enable setting, populate defaults
* framework xml doc update
* Adjust settings, add style selection, replace locale with demonym in dropdown list.
* Test is position is on screen before saving/loading.
* use a default that's actually in the list
