Your welcome Thom. This is an extremely complex system and I am very grateful for all the work everyone has put it in. I'm glad I can contribute, even if it is just a little.
I've spent much of my day wrapping my head around LMCE_Launch_Manager (LM) and decided to try a few things out. Because I don't have a dev environment set up I am really unable to do much with LM, except stare at the source incessantly. So I noticed that there was a lot of logging within the source that doesn't end up in a log. I also noticed that *some* extra logging shows when you run LM from a console. So I commented out LM in the boot scripts and logged in on tty1 and ran LM there while capturing output... Still not all the logging showing but some extra. The first portion of the log is here:
Opening DB connection..
Checking if core is up...
Requested respawning of new children devices
Spawning new children devices - media
Starting device 21 OnScreen Orbiter
Error when querying device status
Finished spawning new children devices - media
Finished respawning of new children devices
>>Performing autostart if configured..
Starting process /usr/pluto/bin/StartCoreServices.sh
The line "Running UpdateAvailableSerialPorts.sh" through to "Finished respawning of new children devices" show that the functions LM::updateScripts and LM::respawnNewChildren are called. This is happening before the LM::doAutoStart function is called and is the premature execution of orbiter.
There are 2 places in code this looks like it could happen:
1) a call to LMdeviceKeepAlive() <-- this seems rather unlikely given that DCERouter is not running to have sent this msg yet
2) either m_bCoreRunning OR m_bMediaRunning are true in the middle of LM::Initialize
Because LM::respawnNewChildren logs that it's calling LM::startMediaDevices it stands to reason that m_bMediaRunning is TRUE in LM::Initialize (supports #2 above). As well, because the logs do not show LM::startCoreDevices being called it seems reasonable to assume that m_bCoreRunning is FALSE (especially since the autostart core routines seem to run after LM::respawnNewChildren), **edit: it's also the only way that m_bMediaRunning wouldn't have an opportunity to be set false...
So... My hypothesis at the moment is that m_bMediaRunning is erroneously being set TRUE during one of the LM:initialize_* functions. I'm not sure what else may or may not be happening in between because what is/isn't logged seems kinda random to me.
Wait... What about this:
m_bMediaRunning is never assigned an initial value and has the possibility of not being assigned a value of FALSE during the LM::initialize_* functions. m_bMediaRunning can only be set FALSE if m_bCoreRunning is TRUE during LM::initialize_Start (when checkMedia() is called). So, sketchy again on the C++ but... will the memory location that m_bMediaRunning points to not just contain whatever was in the memory location beforehand? And if it contains a 1 and m_bMediaRunning *is not* set FALSE somewhere then it could be TRUE? If this is the case it would be just a matter of setting m_bMediaRunning=false at the top of LM::initialize_Start()...(or somewhere else)?
This could also explain why some people experience the problem and some don't.
I might be completely crazy here... I've been beating my head into this monitor for a while...