Millisecond Forums

Downloading a huge number of files (as in this case > 1000 images) will inevitably take quite a substantial amount of time -- the number of files Inquisit has to download does cause a noticeable performance hit, i.e., downloading 1000 images (even if they are small in terms of file size) will take much longer than downloading 10 fairly large images.

During that download process it may appear (to the OS) that the application has become unresponsive, but it's actually still quietly downloading files in the background. Unless there is some other additional problem, the experiment will start eventually *despite* the apparent unresponsiveness.

Since you are hosting the images on your own web space, you can / should check those server's logs:
- To verify that files are being downloaded.
- Rule out bandwidth, etc. issues on the server-side. If, for example, the server terminates a client's connection after some amount of time, then Inquisit will not be able to retrieve the remaining files.

Hope this helps.

Here's an idea to maybe make the download process a little smoother and informative for participants. Overall, it is a bit hack-ish, but could be useful nonetheless.

It is possible to download the image files in several smaller "chunks" before the "actual" experiment that relies on those images. You may want to play around with the size of the chunks, i.e., decide whether downloading 50, 100, or 200 files in one swoop works better. For the sake of example, I'm assuming downloading 4 sets of 250 images each (for a total of 1000).

- Create a file called "batch.iqx" and register that as your active web script. "batch.iqx" would contain something like this, where the final file "actual_experiment.iqx" is your experiment proper.
<batch>
/ file = "download_image_batch_01.iqx"
/ file = "download_image_batch_02.iqx"
/ file = "download_image_batch_03.iqx"
/ file = "download_image_batch_04.iqx"
/ file = "actual_experiment.iqx"
</batch>


- The first file,  "download_image_batch_01.iqx",  would contain the following:
<defaults>
/ windowsize = (640px, 800px)
</defaults>

<block statusblock>
/ trials = [1=statustrial]
</block>

<trial statustrial>
/ stimulusframes = [1=statustext]
/ validresponse = (0)
/ trialduration = 5000
</trial>

<text statustext>
/ items = ("Download 25% completed. Thanks for your patience!")
</text>

<picture download>
/ items = downloaditems
</picture>

<item downloaditems>
/ 1 = "image_001.jpg"
/ 2 = "image_002.jpg"
...
/ 250 = "image_250.jpg"
</item>

where "image_001.jpg" to "image_250.jpg" are the first 250 images required by the experiment proper.


- The next script, "download_image_batch_02.iqx",  would then contain
<defaults>
/ windowsize = (640px, 800px)
</defaults>

<block statusblock>
/ trials = [1=statustrial]
</block>

<trial statustrial>
/ stimulusframes = [1=statustext]
/ validresponse = (0)
/ trialduration = 5000
</trial>

<text statustext>
/ items = ("Download 50% completed. Thanks for your patience!")
</text>

<picture download>
/ items = downloaditems
</picture>

<item downloaditems>
/ 1 = "image_251.jpg"
/ 2 = "image_252.jpg"
...
/ 250 = "image_500.jpg"
</item>

i.e., the next chunk of 250 images, and so forth for the remaining ones.

In theory, that should (1) avoid the "apparent unresponsiveness" issue provided the chunks aren't too large (go for 100 files per chunk rather than 250), (2) give participants a better idea about what's happening / what the download status is. If a given participant experiences a download issue, the above setup would also give you more fine-grained info -- i.e., at what stage / during which chunk the process failed.

Hope this helps.