Meeting about mworks issues with movies/ipad

Hi Chris,

I ran into various issues trying to show movies on the ipad for behavioral testing. I will try to also summarise everything in writing but it is enough that it may be best to also have a meeting about this.

Briefly, the issues are such that I cannot seem to show more than 30 different movies (1s, not that high resolution, that’s like 2MB) due to loading issues, + there are unpredictable timing issues even then, + there can be movie freezes and other timing issues when trying to get around this problem by using load/unload of stimuli. + I found a feature of your cache-loading of stimuli that can easily become a bug for end-users and gave me quite some headache.

Alina

Hi Alina,

Some of the performance issues you describe may be fixed by recent changes to MWorks. Would it be possible for you to package up this experiment and its associated files and put them on Dropbox? Running it myself would be the quickest way for me to assess whether the newer code will perform any better.

In any case, I’m happy to have a meeting to discuss this. Would this Friday morning (9/3) work for you?

Cheers,
Chris

Hi Chris,

Happy to meet from about 9:30am, I have a monkey to take care of before that.

Everything pretty much is on dropbox, I will set up a version for you that produces one of the bugs and tell you what other bugs happen with other variants, before Friday and share it with you.

Hi,

Just shared a folder with you on dropbox. Start the task in mworks using test4Chris.mwel in the subjects subfolder.
There are a lot of notes in the test4Chris.mwel on what we tried so far, and you can comment the current movie set and uncomment a larger set to see it fail.

Further, base_2movie_protocolNoLoad_4test.mwel added in place of base_2movie_protocolNoLoad is a version that walks through the task at a reasonable pace so you don’t have to click anything to make the movie show. In that version, if you search for load/unload you find commented load/unload commands if you need to know where I tried them

I hope everything can be solved with just an update… fingers crossed!

Alina

Hi Alina,

If possible, before our meeting, can you check the model number of the iPad you’re using? You do this by looking at the back of the device or using the Settings app (instructions). The model number should be in the form “Axxxx”, where the x’s are numbers.

If you don’t have time, that’s fine. We can figure it out later.

Thanks,
Chris

I will look now

The model number is A1893.

Hi Alina,

Sorry for the delay in getting back to you about this. I think I’ve figured things out.

First, there is an issue in your experiment code, although not in the state system logic as I initially suspected. The problem is that you unload the movies before you dequeue them. This leads to the sporadic error messages about stimuli not being loaded, as the display update thread sometimes gets a chance to draw another frame between the unload and the update_display action. I believe the premature unloading is also the cause of the freezes and crashes you saw. Although trying to display an unloaded stimulus shouldn’t result in anything more than an error message, I think there are some edge-case bugs that are triggered in this situation. Anyway, the correct way to unload a stimulus is

  1. Dequeue
  2. Update display
  3. Unload

When I changed your code to work that way, I never saw another freeze or crash, even when I let it run for hundreds of trials.

Second, the unpredictable timing issues were tricky to unravel, but they turned out to result from a pathological interaction between the thread that updates the stimulus display and the one the runs the main experiment logic. I believe I’ve sorted that all out now. With the fixes in place, my tests with your experiment do still occasionally produce the “update_stimulus_display action took more than two display refresh cycles” warning. However, the delay is never more than a few refresh cycles, and the experiment timing isn’t otherwise affected. I believe these warnings result from normal system load, where the OS occasionally must delay MWorks code to run other tasks. In other words, I don’t think there’s much you can do about them other than get a newer/faster/more powerful iPad.

If you want to test out these fixes, I’ll need to install the latest MWorks code on your iPad. The quickest and easiest way to do this is for you to just give me the iPad, so that I can install using Xcode on my own Mac. Alternatively, I can create an ad hoc distribution for you. This isn’t hard, but it requires me to register the device ID for your iPad. You would need to provide me with the device ID beforehand. Once I create the ad hoc build, I’d share the IPA file with you via Dropbox. You’d then have to install it using Xcode or Apple Configurator 2, both of which are available from the Mac App Store.

Cheers,
Chris

Hi Chris,

Thanks for figuring this out!

It’s probably good to document somewhere that this dequeue/update/unload is the correct sequence, even though it seems very obvious in hindsight.

Also very interested to learn what that pathological interaction is!

I will check which iPad we can use with Michael and just hand it to you, hopefully soon.

Alina

I just tested this for a few hours and it seems to be running smoothly!

Thanks again!

Great! Thanks for letting me know.

Chris