Recently we received a question about crashing while calling FBPlayerControl::GotoStart() from within a real-time device engine thread. It seems working fine up to MoBu 2014, but crashes in MoBu 2015.
Actually, it seems working fine in previous MoBu releases, but as the best practice, it’s not recommended because the SDK documentation clearly mentions that some methods like DeviceIONotify() and DeviceEvaluationNotify() are called by the Real-time engine thread, and they should consume as little CPU time as possible and return as soon as possible. So it should contain only minimal operations, and especially should avoid UI related operations like FBPlayerControl::GotoStart().
Back to the issue – what if you’d like to control the player using an external device and access the FBPlayerControls from these methods?
To implement such feature, you should move the UI operation codes (FBPlayerControl::GotoStart()) out of the real-time engine (DeviceIONotify() and DeviceEvaluationNotify()) methods,
and cache the status of the operation from an OnUIIdle callback and call the FBPlayerControl::GotoStart() from there. I wrote a code snippet below to demonstrate how to solve the crash issue mentioned at the beginning of the post.
Initialize:
m_NeedToPlay = false; FBSystem().TheOne().OnUIIdle.Add( this,(FBCallback) &ORDevice_Template::EventUIIdle );
Cache the status in DeviceEvaluationNotify:
bool ORDevice_Template::DeviceEvaluationNotify( kTransportMode pMode, FBEvaluateInfo* pEvaluateInfo ) { ... ... if(***) m_NeedToPlay = true; return true; }
Call the UI operation in a UI Idle event:
void ORDevice_Template::EventUIIdle(HISender pSender, HKEvent pEvent ) { if(m_NeedToPlay) { FBPlayerControl player; player.GotoStart(); } m_NeedToPlay = false; }
Comments
You can follow this conversation by subscribing to the comment feed for this post.