possible bug: missing file error

[sten_knutsen]

I was running through my experiment and when I got to trial 76 (my trials are hard coded, not randomized) I got an error that "The file 205_frog_shove_monkey.mp3 is either missing or in an incorrect format. Please fix the problem and preview again."
I checked and saw that that file did indeed exist; but just for kicks, I decided to upload a new file (205_frog_shove_monkey_copy.mp3) and updated the audio stimuli for trials 76 to reflect the new filename in "content".
I ran the experiment again, but this time I got the error "The file 205_frog_shove_monkey_copy.mp3 is either missing or in an incorrect format. Please fix the problem and preview again."

So the "missing file" did not seem to be the problem.
Next, I went into Procedure and deleted trials 1-74 from the experimental block to see if I could get trial 76 to play at all.
I ran the experiment again, and trial 76 played perfectly, no error message.
So why would there be an error message when I started with trial 1 and went to 76, but not when I started from trial 75?
Next, I put back trials 1-74 so the block was complete again. Now I wondered, could this have something to do, not with the fact that there's something wrong with trial 76, but there is something buggy going on when this block reaches the 76th trial position in the block.
To test this, I deleted just trial 76 from the block, so now the trials would proceed from 1-75 and then 77. My hypothesis was that if there is something wrong with the 76th position, I would get an error message about trial 77's audio file. . . .and that's exactly what happened.
Any idea what's going on?

[Ting]

Hi Sten,

This is a known issue - you should be able to see the "extremely urgent" message on your study editing page that says: *Extremely Urgent*: A new bug/limitation in Chrome 92 will prevent some studies from running successfully, if the studies feature more than 75 audio / video stimuli or audio responses (not the background one) in total. Unfortunately the only solution at this moment is to ask your participants to use Firefox. Please see this forum post for details. Thank you for your patience and understanding.

This forum post describes it in details: https://discuss.findingfive.com/showthread.php?tid=129

Any question please let me know.

Ting

[Ting]

Hi Sten,

We also emailed researchers about this issue who elected to receive "critical system updates" emails in their profile, as early as on Tuesday. If you could consider signing up for these alerts, you'll be in the first to know about such issues. Thanks!

Due to privacy regulations such as GDPR, we can't send you emails if you choose not to receive them, even for important issues like this one. We do recommend all researchers stay on the "critical system updates" list for situations exactly like this.

You can also follow us on Twitter to receive such updates. We are @updateFF on twitter.

Ting

[sten_knutsen]

Ok, good to know! Thank you for the response!

[Ting]

You are most welcome!

We have burned some midnight oil and put in a workaround for Chrome 92's odd limitation. We are doing so because Google estimates that the "fix" will only start to be available around Aug 6 to Chrome browsers on Windows/Mac/Linux, and worse, the built-in Chrome in Chromebooks won't get this fix until much later in August.

The workaround should work pretty well, but it also represents a pretty dramatic rewrite of how FF handles audio and video stimuli. To err on the side of caution, we have updated only the testing server with the workaround. Can you help us test our new solution and see if your experiment works under Chrome now? You can go to https://testing.findingfive.com - it'll look identical to the main production server, but it runs on a beta version of FindingFive, and your studies will behave slightly differently.

Thanks!