Crash with FBPlayerControl

[pinata]

Hi.

Im working od device for mobu 2014, and have a problem with FBPlayerControl. Everytime I try to use:

void SetRecord()
{
	FBPlayerControl().Record(false, true);
	FBPlayerControl().Play(true);
}

mobu crashes... The same happens with parsing lines to python, and with all true/false configuration.

Everything is fine, when I use only FBPlayerControl().Play(true) or .Stop()

I tried to bind this function in FBTool to some button, and it works ok...

Any ideas? 🙂

[mattdenton]

Hi,

I'm also having FBPlayerControl issues!

I find MB screen sometimes freezes and eventually crashes when using a step command such as GotoStart() or StepForwads().  Yet my plug-in is still running, as I can see in the debug screen debug messages when I send commands? Very irritating!

[mattdenton]

Ok, so as far as I can tell MB does not like the FBPlayerControl functions being called from within DeviceIONotify(), this didin't used to be the case. I have written a simple test device using the oredevice_template example. WIthin the example I added some buttons to the UI which would trigger play, stop and rewind. This works fine if the FBPlayerCOntrol function is called from the UI, but if I pass a paramerter to the mDevice class, which is later processed in the DeviceIONotify() routine this will eventually cause MB to crash.

You may wonder why I need to send FBPlayerControl commands from within DeviceIONotify(), this is because my device controls the Player from over a UDP port and as such controls the FBPlayerControl from within DeviceIONotify() . This has worked on previous version of MB right down to 7.5.

Any thoughts?

[sylvain.chague]

Hi,

I am having the same problem. Calling "FBPlayerControl().Stop()" from DeviceIONotify crashes Mobu.

However calling FBPlayerControl().Record(true, true) or FBPlayerControl().Play() works fine.

Did you manage to find a solution to this problem?

[mattdenton]

Hi,

Yes I did find a work around from Autodesk. Apparently you shouldn't be sending Transport control from within the real-time events such as DeviceIONotify(). This used to work but now crashes! The solution was to install the EventUIIdle event, and do all transport control from within this callback, something like:

bool my_device::FBCreate()
{
// ...... stuff

FBSystem().TheOne().OnUIIdle.Add( this,(FBCallback) &my_device::EventUIIdle );
}



void my_device::EventUIIdle(HISender pSender, HKEvent pEvent )
{

FBPlayerControl mPlayer;

// get current transport command from hardware layer

unsigned char msg = mHardware.GetTransportCommand();

switch( msg )
{
case BYTE_TRANSPORT_PLAY:
  mPlayer.Play();
  break;

case BYTE_TRANSPORT_STOP:
  mPlayer.Stop();
  break;

// etc...
}

}

The down side of this solution is that the transport commands now have additional latency, at least that's what I see in my system.

[sylvain.chague]

That works fine thanks.

The other downside of this method is that the device UI has to be visible / "active" so that this works.

[mattdenton]

---

@sylvain.chague wrote:

That works fine thanks.

The other downside of this method is that the device UI has to be visible / "active" so that this works.

---

Hi, I hadn't noticed that the UI had to be visible? I'm sure my useres would have complained by now if that was the case.. will check.

[mattdenton]

Hi,

Just checked on MB2014, device UI does not need to be visible for this to work.

Matt.

[sylvain.chague]

Actually, I had implemented the callback in the device layout class (ordevice..._layout.cxx).

I moved it back to the device class (ordevice..._device.cxx) and it now works perfectly fine.