Millisecond Forums

Please update your experiment to use the latest Inquisit Web version (5.0.3.0) via its settings. That should resolve the crashing issue after the 1st script in the <batch>.

I see there is now a newer version (5.0.4). Should I update to that version now?
I received a complaint that an add-on kept crashing -- could this be related?

Thanks!

Yes, I would definitely recommend updating to the latest version via your experiment's settings. This may well resolve the problem. If not, please update this thread. Please include a link to the respective web experiment and whatever additional information you may have received from participants (the exact symptoms, where the crash occurs, any error messages they may have seen, their OS, etc.).

Thanks!

Ok, I updated to the latest version but had another complaint about what seems like the same issue. 

The participant was running Inquisit 5.0.4 using Windows 8.1 and received the standard windows error message "This program is not responding and has crashed". This occurred after the final practice round (script called conflictBoundRetPractice). The start page of the experiment is http://research.millisecond.com/knorman/conflictBoundRun.web. 

Please let me know if you need any more information.

Thanks!

Thanks for the update -- I don't think this is the same problem as the original one: Web player crash after the 1st script in a <batch>. That was an Inquisit bug affecting Windows (it did not affect OSX or iOS), and that one is definitely resolved in both 5.0.3.0 as well as the current 5.0.4.0.

The "This program is not responding..." message your participant reported is most likely caused by something else entirely. First a little background how <batch> elements work on the web. When you have

<batch>
/ file = "A.iqx"
/ file = "B.iqx"
/ file = "C.iqx"
</batch>

The web player will download "A.iqx" and all the files "A.iqx" may require (e.g. images). Once those files have been downloaded to the participant's device, "A.iqx" will be run. Once "A.iqx" has finished, the data gathered for script A will be uploaded and the web player will then proceed to download the next script "B.iqx" and its associated files...

Looking at your <batch> and the scripts / files involved

<batch>
/file = "ConsentformScript.iqx"
/file = "worker_id.iqx"
/file = "conflictBoundPractice_v2overlap.iqx"
/file = "conflictBoundRetPractice.iqx"
/file = "conflictBoundMain.iqx"
</batch>

the "not responding" issue occurs after "conflictBoundRetPractice" has finished, i.e. during the download process for "conflictBoundMain.iqx" and associated files. As far as I can see, Inquisit has to download _a lot_ of files for "conflictBoundMain", on the order of several hundred images (substantially more than for any other scripts). That takes some time (the sheer amount of files does cause a certain download performance hit, regardless of the sizes of the individual files involved, i.e., even if they are relatively small). During that time, it may indeed look as if the application has become unresponsive (although it is in fact still downloading files in the background); if -- in addition -- the participant's internet connection experiences a temporary issue (think: WiFi signal dropping for a short time) or is generally on the slow or unreliable side, the operating system would eventually determine that the application crashed and terminate it.

I unfortunately don't see any immediate workaround for this, unless reducing the number of files involved in / required by the "conflictBoundMain" script is an option.

I hope the above was not too technical or confusing.

thanks! that makes sense. i thought something like that might be the case. unfortunately i cannot reduce the number of images in the current version, however i can potentially split the main script and associated files. do you think splitting it would help reduce the problem or would it be equally likely, just at separate times? 

Splitting the main script could help, I think. You'd then have something along the lines of, say

<batch>
/file = "ConsentformScript.iqx"
/file = "worker_id.iqx"
/file = "conflictBoundPractice_v2overlap.iqx"
/file = "conflictBoundRetPractice.iqx"
/file = "conflictBoundMain_pt1.iqx"
/file = "conflictBoundMain_pt2.iqx"
/file = "conflictBoundMain_pt3.iqx"
</batch>

with each resulting "component" script (pt1 to pt3 in the example) having fewer files to download before it can start to run. That should -- in theory -- decrease the risk of the "unresponsiveness" issue occurring.