Resources Not Loading – Random Points in Experiment

This topic has 11 replies, 2 voices, and was last updated 1 year, 8 months ago by kelly_marshall.

Viewing 12 posts - 1 through 12 (of 12 total)

Author

Posts
February 23, 2022 at 11:55 am #7792

kelly_marshall
Participant

Hello,

I am trying to construct a mouse-tracking experiment that uses audio (.mp3) and picture (.png) resources. Each trial has one audio file and 2 picture choices. Currently, the resources are being loaded from GitHub, using a unique link for each resource (not a zip file). All of the GitHub links have been checked outside of the experiment to make sure they connect to the correct content.

My issue is that at some point during the experiment, I will get a “resources are preloading” message and one of the files (audio or video, different each time) will not load and the experiment won’t be able to continue. In different times attempting to run through the experiment, this happens on different trials, including trials that have successfully loaded several times before. So, it seems not to be an issue with the files/links themselves. I have 3 separate CheckPreloaded functions, one for each part of the experiment (pre-test, training, post-test) that are called at different times during the experiment. Each of the pre, training, and post parts work if I test them as separate experiments. I’ve also tried having everything preloaded at once at the beginning of the experiment and encounter the same issue. I’ve encountered the issue on different computers and using different browsers (chrome, firefox).

My question is what might be causing this issue and whether there is a way to manage the resources in a better way to avoid this? I’ve included the link here: https://farm.pcibex.net/r/MYUGkd/

Thank you!
Kelly

February 23, 2022 at 1:31 pm #7795

Jeremy
Keymaster

Hello Kelly,

Your experiment fetches many resources from GitHub’s servers: your code points to the GitLink_* columns of the tables pre.csv, post.csv and training.csv, which represent a total of 265+216+216 = 697 unique URLs (training.csv contains redundant references). When I opened your demonstration link and opened my browser’s console, the Network tab listed a total of 406 successful requests to raw.githubusercontent.com. Besides those, there are 812 (=406*2) other requests to GitHub’s servers, which come upstream from the 406 aforementioned ones. In total, then, there was a total of 1218 requests to GitHub, and it took about 4min to complete them all

At the end of the day, I was still missing 291 requests. I am not sure what happened to those, as my Network tab does not show any unsuccessful request, but most likely they were dropped because of the many requests that were actually sent. Usually, the more requests you send within a short time to a server, the slower they will be processed, and some of them might even be blocked. PennController tries to prevent flooding the distant server with requests by only allowing for 4 concurrent requests (new requests are sent once older requests have successfully resolved). That being said, in your case, it could be that GitHub blocks the requests of an experiment session after a few hundreds, and/or that PennController fails to free new slots

My suggestion is that you consolidate your resources into zip files (you could have separate zip files for different sets of trials if you’d like) and host them on a dedicated webserver or an S3 bucket, for example. Then you’ll have just as many requests as you have zip files, making it much more likely that they all succeed, and the zip files will contain all your resources, so once they’ve been downloaded you don’t run the risk of missing one resource here and there

If that’s not an option you can pursue, I would at least replace the GitHub URLs from your tables with direct URLs pointing to the raw.githubusercontent.com domain, so you don’t generate three times as many requests as you really need. You could also try to balance the requests to GitHub’s servers and to the farm’s server more evenly, in the hope that no server would block the requests

Let me know if you need assistance

Jeremy

February 23, 2022 at 5:48 pm #7802

kelly_marshall
Participant

Hi Jeremy,

Thank you so much for looking into this! I will try out the zip files option.

-Kelly

July 21, 2022 at 2:00 pm #8298

kelly_marshall
Participant

Hi Jeremy,

I have been running into a possibly related issue with a new version of this same experiment.

After your previous response, I was able to get the experiment working successfully by keeping the picture resources local and only making 1 request to GitHub per trial for the audio (zip files weren’t possible for a few reasons with our current setup). I successfully ran 2 pilot experiments with no issues.

In the most recent version, there are more stimuli but the setup is the same. On several test runs through, everything worked correctly for me in the last 1-2 weeks. Beginning this week, participants have been having issues with the stimuli not loading at different points throughout the experiment, and I have also had issues on test runs through. Unlike last time, what is not loading is now sometimes the pictures or instructions that are stored in local resources and sometimes the audio from GitHub.

My question is whether there is a different issue, or if I am potentially running into the same problem now that the number of stimuli increased.

Here is a link to the experiment demo: https://farm.pcibex.net/r/JTnlcu/

Thank you!
Kelly

July 21, 2022 at 5:49 pm #8302

Jeremy
Keymaster

Hi Kelly,

My guess is that it’s just too many resources. You’re requesting close to 700 files: it’s just very likely that at least one of those requests will fail for any number of reasons, and still quite likely that more than one will fail. Distributing the requests over two different servers (github and the farm) probably helped, but to be honest, I’m surprised you were still able to run 2 pilots with no issues

As I mentioned in my previous post, one minor thing you could do is replace the https://github.com URLs with https://raw.githubusercontent.com URLs so the browser doesn’t have to send as many requests, i.e you can replace https://github.com/USERNAME/REPO/raw/main/FOLDER/SUBFOLDER/file.mp3 with https://raw.githubusercontent.com/USERNAME/REPO/main/FOLDER/SUBFOLDER/file.mp3. It won’t solve everything, since as you said you’ve also experienced issues preloading files from the farm, but it’s still a step in the right direction

Amazon offers 5GB of S3 storage with AWS Free Tier (valid 12 months). You could upload a zip file there (see this post for tips on how to set things up so your experiment can download the zip file from S3)

Jeremy

August 4, 2022 at 3:00 pm #8322

kelly_marshall
Participant

Hi Jeremy,

Thanks again for your help! I now have a server set up here: https://kellymarshallresearch.umd.edu/DDMMaterials which includes the materials in a zip file and .htaccess files per the Managing Resources Guide. I can download the zip file from a browser but when I try to run

PreloadZip(“https://kellymarshallresearch.umd.edu/DDMMaterials/DDMZip_AllInstbias.zip”);

in my experiment, I get the following error:

InvalidStateError: Failed to read the ‘responseText’ property from ‘XMLHttpRequest’: The value is only accessible if the object’s ‘responseType’ is ” or ‘text’ (was ‘arraybuffer’)

I’ve checked that there’s no extension like .txt on the .htaccess and the text is copied directly from the guide, but I’m wondering if there’s some other issue there.

Best,
Kelly

August 4, 2022 at 5:02 pm #8323

Jeremy
Keymaster

Hi Kelly,

Currently, requests to https://kellymarshallresearch.umd.edu/DDMMaterials/DDMZip_AllInstbias.zip do not return the necessary allow-control-origin header, so the zip file cannot be downloaded in the background from a script that lives outside the kellymarshallresearch.umd.edu domain

If you copied the code from the guide, then you should have this line:

Header always set Access-Control-Allow-Origin "*"

Make sure to double-check that you either have "*" or "farm.pcibex.net" (or whatever domain you run your experiment from)

You’ll also want to make sure that .htaccess lives directly in the directory at https://kellymarshallresearch.umd.edu/DDMMaterials/ and not in a parent folder, for example. I know for a fact that it is possible to configure .htaccess correctly on the UMD servers, since this user was able to

If everything seems properly configured but you still cannot access the zip file from the experiment, consider reaching out to an IT person at your institution

Jeremy

August 4, 2022 at 5:19 pm #8325

kelly_marshall
Participant

Thanks for your quick response!

I double checked that the “*” was in that line of the .htaccess file and .htaccess is in the DDMMaterials folder.

I also tried to set up an Amazon S3 bucket and I get the same error if I try to use PreloadZip() from that link. I think I’ve gone through and made everything public and sent the CORS information as described on other posts on this forum. If I’m getting the same error could it be something about the zip file itself?

Here is the link for the AWS server: https://kellymarshallresearch.s3.amazonaws.com/DDMZip_AllInstbias.zip

August 4, 2022 at 5:30 pm #8326
Jeremy
Keymaster
Yeah the S3 link does not send the header either, so you’ll face the same problem

I just realized the link I gave to the other post about S3 does not discuss CORS settings. AWS has documentation about how to create a CORS configuration. In your case, you want to use a JSON configuration like this:
```
[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET"
        ],
        "AllowedOrigins": [
            "https://farm.pcibex.net"
        ],
        "ExposeHeaders": []
    }
]
```
Jeremy
August 4, 2022 at 6:18 pm #8328

kelly_marshall
Participant

Ah, okay. Thanks!

I updated the CORS configuration to match what you have there.

When I am editing my experiment and press refresh, I continue to get the same error. But, when I open the demo link (https://farm.pcibex.net/r/JTnlcu/) or open in new tab, I don’t get any errors and when I look in the log I see the following : [17:55:45] Download of https://kellymarshallresearch.s3.amazonaws.com/DDMZip_AllInstbias.zip complete.

The experiment seems to work and I can hear audio that is not in the local resources but should be coming from the zip file. Does this mean it’s working okay even without sending the header? Or do these kinds of errors just not show up in the demo?

August 4, 2022 at 6:37 pm #8329

Jeremy
Keymaster

Yes, both the “complete” message and the successful playbacks mean that it is working. It looks like all CORS requests simply fail when using the Preview window, so you’ll have to take your experiment in a separate tab if you need to test trials that use files from the zip file. Unfortunately I’m not sure I could do much about that, given the general constraints that browsers put on embedded pages like the preview frame

Jeremy

August 4, 2022 at 6:39 pm #8330

kelly_marshall
Participant

Makes sense. Thank you for looking into these issues!
Author

Posts

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.