Well, I decided to test how long it might take to hit some of the points. Specifically for this first test I set the breakpoint on the next line in the settings plugin after the line "if(function==eFunction.pluginLoadingComplete).... " to correspond to when the plugin loading is complete. I let OM run, loading up with the android skin, and it took 11 minutes and some odd seconds to hit that line... I sure hope I can figure out a way to improve that speed. At least I know it's just something that needs to run longer than I am used to for the time being.
I suspect the same thing for the indexing music problem, and I bet time will fix that as well.
Just implemented a simple text line so I can at least see when the plugins loading are complete, so atm it's working but not optimal.
EDIT: Just found something else, just not sure what thread/code might be causing it. I have noticed that if the plugins don't load within the first so many seconds (like 5ish) of OM starting, I will get the dreaded ContextSwitchDeadlock error. Now time to track this down:
The CLR has been unable to transition from COM context 0xecc18 to COM context 0xecaa8 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.