These are the errors we are getting. 

These errors point to an issue with the 4th script. Specifically, it points to a graphics issue. Reasons could be:
- Some misspecification of stimulus size / position, or canvas size position in the 3rd or 4th script.
- An issue with the system's display driver.
- The system running out of graphics memory.

I'm having trouble locating the relevant files in the Box link you posted since there's so much extraneous stuff.

Would it be possible for you to just upload a _clean_ copy somewhere, i.e. just the batch script, the scripts (+ any files the scripts require such as images) the batch attempts to run, all in the expected directory structure with names etc. matching what's in the batch? Please leave out all extraneous stuff such as Word or Excel documents, data files, and other scripts not required by the batch at issue. Thanks.

We've been doing some testing and figured out a few things.

• The batch file seems to work if you remove the EMATHFR test from the batch code, which is the only test that uses a second monitor. Currently, we're using this monitor. 
• If you run the EMATHFR code by itself, it also seems to work, but embedding it in the middle of the test like it is now does not. 
• If you start the test with EMATHFR (IDInfo is a one-pager that we don't remove because it's where we input the batch-level parameter, age), then it will run and so will the remaining tests.

Thanks, this is very helpful. Based on what you describe, the switch from single-monitor to dual-monitor in the middle of things is what throws things off (not sure yet whether the problem originates in Inquisit itself or the graphics card driver refusing to switch / returning an error).

A workaround might be to put a small script that uses both monitors at the very start of the batch -- that script need not do anything, need not take any input or last long (it can just time out after a second or two). I'll be looking into your files later on (the download is taking a while) and let you know what I find.

Thanks, this is very helpful. Based on what you describe, the switch from single-monitor to dual-monitor in the middle of things is what throws things off (not sure yet whether the problem originates in Inquisit itself or the graphics card driver refusing to switch / returning an error).

A workaround might be to put a small script that uses both monitors at the very start of the batch -- that script need not do anything, need not take any input or last long (it can just time out after a second or two). I'll be looking into your files later on (the download is taking a while) and let you know what I find.

Hi Dave, 
Would you happen to know anything about batch file discrepancies between different types of computers (if that even exists)? At the moment our batch file runs through most of the files when we run it on our desktops. However, on our surface pros they crash somewhere in the middle. Let me know if you have any ideas, thank you!

Assuming the scripts are those available under the Box link, the only thing I can think of would be resource-exhaustion on the Surface Pros. The scripts involve lots and lots of files, so I can imagine that the Surface devices *might* for example run out of memory somewhere along the way whereas more powerful desktop machines can cope with the overall load. Can you give me a better sense of when / where crashes occur, i.e. is it always during a particular script or even a particular trial or block in a script, or does it seem somewhat random, i.e. sometimes happens sooner in script X, other times it happens later in a different script Y? The latter would support the idea that the Surface devices can't quite cope with the combined load imposed by the scripts.

I think you're right, Dave. We were just about to post with some tests we've run. When we first posted, the script would run if only MATHFR were removed. We added a very small script at the end to collect the timing of the last test, and that was too much. So we then tried breaking up the batch file even further; roughly half of the tests in one batch, half in another, and MATHFR by itself. So far, this is the only way that it works. Am I understanding correctly that Inquisit needs memory for the entire series of tests, not just the one it is currently running? This is unfortunate because one of the key reasons why we purchased Inquisit 5 was for the ability to pass a common, randomly-generated code across all tests administered during a batch. Every time we break up the batch file means it's harder to merge a participant's individual tests back together when there's a problem with the subject id. 

While memory is *mostly* consumed by the currently running script, running several scripts via <batch> causes some additional overhead -- the <batch> script runs in its own thread, has to keep track of things (which script is currently running, is it over, which script is next, etc.?) and the <batch> element also needs to preserve some state beyond that for <batch> <parameters> and <values> used to pass information from script to script.

If you can forego the <paramaters> and <values>, you could get rid of the <batch> and its overhead and execute your script's via a command line script instead -- that command line script could generate a random subject ID which would be identical across all scripts it executes, and thus allow for relatively easy data matching and merging of all tests as before. Since technically Inquisit would shut down briefly between scripts and would not need to keep <batch> state and do housekeeping, the memory consumption overall should be lower.

https://www.millisecond.com/support/docs/v5/html/howto/howtocommandline.htm

https://www.millisecond.com/support/docs/v5/html/articles/batchscripts.htm

Might that be an option?

Thanks, Dave. We've looked into the strategies you've proposed, and although they solve the multiple experiment in a row problem, we just don't think they're feasible for us. This is primarily because our participants are young children and the people who administer the tests to these children have a wide-ranging ability level in technology. Therefore, using command line and batch capabilities just isn't an option. 

Furthermore, we were really hoping that Inquisit 5's new batch file capabilities would solve a couple of issues for us. Most importantly, due to human error with our examiners, we end up with a sizable number of mis-entered subject IDs. This is bound to happen in research with many subjects, but when you have several duplicate subject IDs, it would be nice to have an additional ID that joined the various tests during an assessment. We were hoping to add a randomly-generated assessment ID to complement the subject ID that would persist across all of the scripts of a batch file. Therefore, even if someone mis-entered child #3's subject id as 4 so that we had two assessments with subjectid=4, then we could at least easily keep the multiple tests from each one separate. This would facilitate all of the data merging on the back end. 

Also, I'm a little surprised at the overhead of the batch file. We're only running about 7-8 tests, and the parameters we're trying to use across scripts is minimal so it's hard for me to understand how it might take up a lot of memory. Given our testing results, it seems like the memory load is increasingly roughly linearly with the number of scripts we add to the batch file and the number of files associated with each script, as if it's trying to load all of the files at one time, instead of one at a time. At the present moment, given the number of items we have, there doesn't seem to be a way to administer all of the scripts back-to-back. Instead we have to break up the batch files into 2-3 parts, which eliminates the benefits of an assessment ID to join scripts from the same assessment session. 

I hope this makes sense.

Jeff

The <batch> overhead isn't huge, but when you have a system that's already operating near its limit resource-wise (because, among other things the scripts themselves are relatively demanding / resource-heavy), even small things can make a difference (such as e.g. adding one more script; cf. https://www.millisecond.com/forums/FindPost25111.aspx ). One possible strategy might be to make the scripts themselves a little less resource heavy; for example, you could try using MP3s in conjunction with <video> elements instead of relatively large WAVs in conjunction with <sound> elements. Avoiding massive image rescaling can also save considerable amounts of memory, i.e. you could try converting any images to a resolution near where it needs to be instead of relying on Inquisit to scale e.g. a high-resolution image down to fit a relatively small space on the screen. I haven't reviewed all the images involved in your scripts enough to really say whether there is much to be gained in this particular case, but at least the MP3 vs WAV modification seems worthwhile and may well make a noticeable difference.

To add, I do think the issues and demands (random assessment code independent of the subject ID as a data matching fall-back) are solvable via a command line script, too. That command line script can be made relatively user-friendly and pretty, requiring no more than a double-click to execute essentially. It would then prompt the experimenter to enter a subject and group ID as usual. To generate the fall-back assessment code, the command line script could generate a random number (just like your <batch> does currently) write that to a small file, and that file could then be <include>d in all the actual scripts, i.e. the assessment code would be present in and consistent across all the participant's data files.

I'll see if I can code up a small demo of the above a little later today and post it here to better illustrate what I mean.