PennController for IBEX › Forums › Support › Preloading at a specific point in the trial sequence
- This topic has 2 replies, 2 voices, and was last updated 2 years, 11 months ago by Ncomeau.
July 1, 2020 at 4:03 pm #5744NcomeauParticipant
I recently had a few colleagues run through my experiment and they seemed to have the most issues with zip files preloading properly after having refreshed the page (a significant instance is upon failing the headphone check, I display text saying to refresh the page and try again).
Some things that I’ve observed in debugging myself are:
-The issue only occurs when the page is refreshed with the same withsquare value that was used on the original run. Changing the subset of the data that the participant receives seems to fix it, but changing that value would correspond to changing their experiment entirely with the way group assignment is set up on the prolific/participant recruitment end of things (different withsquare value -> different prolific study). Also, this method is only a fix when the participant’s browser cache isn’t already at a high load (This seems to indicate that the previous runs zip download is held onto despite the refresh). If there’s already a lot in there, it’s the same behavior of the debugger log not saying anything about files being successfully preloaded, and the experiment hanging on the first trial.
-Clearing the browser cache prior to refreshing the page fixes the issue, but I don’t think that’s something I’d be able to reliably get each participant to do.
With this, I was wondering if it would be possible to handle preloading after the headphone check, as at that point the participant would not have any reason to refresh the page.
I’ve tried getting things to work by adding a separate checkpreload function calls for the main and catch trials that are then referenced in the Sequence() after the headphone check, but I keep getting the same behavior of an initial attempt to preload everything as soon as the experiment opens, and then waiting the full 10 sec (Even this is being conservative with how long it usually takes to preload successfully) timeout with nothing new appearing in the log.
Do you have any idea why that might be the case?
Thank you so much for the help!July 1, 2020 at 6:20 pm #5746JeremyKeymaster
The CheckPreloaded command, as its name indicates, creates a trial that only checks that the resources have been preloaded by the time it’s running, and if they haven’t it waits before proceeding to the next trial.
I was unaware of this problem, and I don’t see an immediate solution to it. The only thing I noticed is that it happens to me when I use Chromium, but not when I use Firefox.
I will need to proceed to some tests before I can identify the problem, I’m sorry
JeremyJuly 2, 2020 at 11:46 am #5748NcomeauParticipant
No worries, I think a solid workaround for now would be housing the headphone check in a separate eligibility/screener experiment that gets linked to from prolific, and then linking to our main experiment from there based on a url parameter. That would at least impose that there be no reason to refresh in the main experiment. I’d be interested in hearing more about what’s going on under the hood once you’ve done some testing.
- You must be logged in to reply to this topic.