Sept 2018
For a while, if a video or audio file failed (for whatever reason) the participant would be presented with a blank screen with no further information and the task would cease to progress. Blank screens with no information and stopped tasks are bad. Debugging these issues when they arise has been time consuming for both researchers and Gorilla developers, particularly given their often temperamental and unpredictable nature. For some participants it would be fine, for others it wouldn’t be and throughout all this, activity and workloads on the Gorilla servers would be entirely nominal. If there was a smoking gun out there it was being wielded by Marvel’s Hawkeye (Or DC’s Deadshot, if you’re that way inclined…).
In the absence of being able to prevent these issues from occurring, we’ve concluded that the next best step is to clearly communicate that there has been a problem. Add thorough error messaging throughout the process of loading and presenting video and audio stimuli. This will do three things:
With this, participants won't be left completely in the dark if something goes wrong: they'll have some guidance on what to do next and more useful information to report to the researcher. Researchers will have logs in the participants metrics for when something has gone wrong but gone unreported. Finally, we'll get live reports as these issues occur, which should allow us to better diagnose and advise researchers when these errors occur.
In the following pages, I'll detail the different error messages that can occur: what they mean and how you should respond. For the less technically minded, I'll begin with a simple overview of each error, stating the content of the corresponding error message and the action your should take. For those who need or want more information into what each error message means, I'll be taking a deeper dive into each error afterwards, giving some more technical information and link to further reading.
Before we begin though...
Below you can find an overview of the most common Media related messages (audio, video).
Media Error Messages are provided for all Gorilla Media Components - essentially, any components that play audio or video - with two aims in mind:
Note: you will not get Media Error messages if you are using any embedded media such as YouTube or Vimeo videos.
Follow the links to view more detail on an individual error. Alternatively use the menu on the left to navigate directly to detailed information page for a particular error message.
Error message seen by participant: "No source for the media could be found! Try refreshing the page. If the problem persists, contact the researcher for the experiment”
Error message seen by researcher: "No source for the media file [Gorilla inserts name of stimuli here] could be found! Most likely this is because the file has not been uploaded to your stimuli list or its name has been typed incorrectly in the spreadsheet”
Cause: Either the stimuli hasn't been uploaded or it has been named incorrectly in the spreadsheet. View more details on 'source not found'.
Solution: Double check the contents of both your uploaded stimuli and your spreadsheet and correct any mistakes!
Error message seen by participant: “Something has cancelled downloading the media for this trial. If you have anything setup to limit downloads on your browser or device, or prevent video/audio from playing, you may need to deactivate it to proceed. Then, try refreshing the page”
Error message seen by researcher: “The fetching process for the media resource was aborted by the user agent at the user's request”
Cause: Something on the participants side has halted the media from downloading. We don't know specifically what can cause this: a possibility is a client side tool for limiting download sizes. View more details on 'MEDIA_ERR_ABORTED'.
Solution: Consider compressing the size of your stimuli or using file formats that are typically smaller.
Error message seen by participant: “There's something wrong with your internet connection! Try refreshing the page to re-establish the connection. If that doesn't work, check your router or change from wi-fi to a wired connection, if possible and then refresh the page”
Error message seen by researcher: “A network error of some description caused the user agent to stop fetching the media resource, after the resource was established to be usable”
Cause: The participant's connection to Gorilla has become unstable/unreliable. View more details on 'MEDIA_ERR_NETWORK'.
Solution: This is almost certainly a problem on the participants side, so we recommend the try refreshing the page, resetting their router or switching to a different connection mode (wired instead of wireless). Additionally check firewall and proxy server settings.
If the problem occurs for a large number of participants, check out the Gorilla status page and twitter feed @GorillaPsyc to see if there are any issues ongoing on the Gorilla Server.
Error message seen by participant: “Your browser has detected a problem with the media and can't play it. You can try refreshing the page but if the problem persists, you'll need to report this issue to the researcher”
Error message seen by researcher: “An error of some description occurred while decoding the media resource, after the resource was established to be usable”
Cause: The audio or video file is in some way corrupted. View more details on 'MEDIA_ERR_DECODE'.
Solution: If it is an edited stimuli, try going back to the original source file.
If it is the original, try running it through a video/audio validation tool, which sometimes come with audio/video editing suites.
Error message seen by participant: “Something has gone wrong while trying to download the media. Either the audio file is missing or your browser cannot play it. You can try refreshing the page but, if the problem persists, you'll need to report this issue to the researcher”
Error message seen by researcher: “The media resource indicated by the src attribute was either missing or not supported by the browser”
Cause: The common reasons for this message coming up aren't applicable to Gorilla media components, so if this error message arises, get in touch with us via the support contact form! View more details on 'MEDIA_ERR_SRC_NOT_SUPPORTED'.
Solution: Get in touch with us via the Support Contact Form.
Error message seen by participant: “No media element present: While trying to load the media, no containing media element could be found!”
Error message seen by researcher: “No media element present: While trying to load the media, no containing media element could be found!”
Cause: Something that should only be a hypothetical error has actually happened! View more details on 'no media element present'.
Solution: Check that the sky isn't currently falling outside and then get in touch with us via the Support Contact Form.
Error message seen by participant: "No source for the media could be found! Try refreshing the page. If the problem persists, contact the researcher for the experiment”
Error message seen by researcher: "No source for the media file [Gorilla inserts name of stimuli here] could be found! Most likely this is because the file has not been uploaded to your stimuli list or its name has been typed incorrectly in the spreadsheet”
This is a simple one and, honestly, by far the most common problem that occurs when running a task, with any kind of uploaded stimuli. Either the researcher hasn't uploaded the stimuli in the Stimuli tab or it has been named incorrectly in the spreadsheet. These names need to match exactly including upper case letters, the file extension, and any extraneous spaces.
As it stands, if a stimuli can't be found there will still be a 30 second delay before the trial loads as Gorilla tries (fruitlessly) to prepare the stimuli for presentation. There are ways to prevent this but it fell outside the scope of this phase of improvements. We'll be looking at it again in the coming months, alongside improvements to the stimuli preloading system in Gorilla as a whole.
Long overdue 2022 update: The fact that this was one of the most common issues researchers encounter with stimuli was a strong motivator for finding better ways of preventing this. And we did indeed do just that...well, um...well, a while ago. Years ago. We just forgot to update this page. Now the spreadsheet is dynamically linked to the stimuli and screens/displays and the cells in the spreadsheet will highlight green when Gorilla has found matching content, and will remain white if it hasn't. It should now be easy to see whether the stimuli have been named correctly in the spreadsheet.
Error message seen by participant: “Something has cancelled downloading the media for this trial. If you have anything setup to limit downloads on your browser or device, or prevent video/audio from playing, you may need to deactivate it to proceed. Then, try refreshing the page”
Error message seen by researcher: “The fetching process for the media resource was aborted by the user agent at the user's request”
The participant, or something on the participant's device, stopped the media from being downloaded. The latter is more likely. Something like a third-party or inbuilt tool that limits downloads on a device is the most likely culprit.
There's nothing Gorilla can do to override such functionality where used and, indeed, there shouldn't be. If a participant has set a download cap, we have no right to subvert it.
To prevent this from occurring for other participants, consider compressing your stimuli or using a smaller file format where possible. If using large, or a large number of, stimuli is unavoidable, warn participants before they start the tasks, giving them the option to leave if they wish.
As we don't expose any controls that would enable it, it is unclear how the participant themselves could be manually halting the download on the task screen, though this is the other possible cause for the error. If this error occurs, get in touch with Gorilla, providing as much detail on the circumstances surrounding its occurrence as possible and we'll investigate.
Error message seen by participant: “There's something wrong with your internet connection! Try refreshing the page to re-establish the connection. If that doesn't work, check your router or change from wi-fi to a wired connection, if possible and then refresh the page”
Error message seen by researcher: “A network error of some description caused the user agent to stop fetching the media resource, after the resource was established to be usable”
The media can't be downloaded because of a problem with the connection between Gorilla and the participant. 95% of the time this will be a problem with the participant's internet connection.
During normal browsing, a participants internet connection is only significantly utilized when first loading a page. After that, it sits idle while until the participant changes the page (clicks a link etc.) As a result, small disconnects can be easily missed or masked.
However, during the course of an experiment, Gorilla requires near continuous access to a participants internet connection: we're preloading data for the next trials, constantly uploading progress data and metrics. Small 'blips' in a connection will become noticeable and be disruptive in these conditions. Another important note is that, the speed of the participants connection will have no barring on its overall reliability. I used to get close to 1Gb download speed in student halls at Cambridge — I would still get infuriating disconnects during utterly critical and time-sensitive, um, games of League of Legends, that no one else on my team would experience.
Refreshing the page will usually take enough time to pass through the momentary connection blip and the task can progress smoothly again. In more serious cases, the participant may need to restart their router, try connecting to the internet in a different way (wired vs wireless) or switch device altogether. My new mobile will happily connect to any wireless connection on the planet — my decade old laptop will be lucky to connect for more than 30 seconds at a time.
All that said, yes, Gorilla does experience disruption which affects participants very, very occasionally. This is almost always a result of actions that are outside of your control — Azure promises our services will be available 99.95% of the year, but this still adds up to a notable amount of downtime each year. If a lot of participants are getting this error message, and you've ruled out any issues associated by location, then check out the Gorilla status page and the Twitter feed. Even short (< 1 second) disruptions are usually listed on the Gorilla Status page and anything significantly longer than that will almost always go onto our twitter page. If still in doubt, don't hesitate to contact us!
Future development: While we can't do anything to improve difficulties at the participants end, we can make sure that downtime on the Gorilla side, and the effects of that downtime, are as small as humanly possible. Note that, even with all their resources, services like Facebook and Twitter still experience outages — its a risk that's impossible to eliminate completely. Regardless, we are continually improving Gorilla's performance, building in more redundancies and fail-safes, and making the impact of unexpected downtime as negligible as possible. As more of these systems come online, we'll let you know about them!
Error message seen by participant: “Your browser has detected a problem with the media and can't play it. You can try refreshing the page but if the problem persists, you'll need to report this issue to the researcher”
Error message seen by researcher: “An error of some description occured while decoding the media resource, after the resource was established to be usable”
While the media resource can be accessed, downloaded, and started playing, something has gone wrong while actually playing it. Corruption in the media itself is the most likely cause here. If this is an edited video or audio file, try going back to the source file and see if the error still occurs using that. If the media is already the original, you'll need to find a way to scan it for errors or corrupt bytes. Your institution's technicians might be able to help with that!
This is an issue we can reproduce locally (and one of the incidents that prompted this investigation). Back in March/April 2018, a video in our internal testing rig stopped working but only in Chrome! The task would hang at the end of the video, rather than moving on to the next screen. It turned out that, in Chrome, playback was actually stopping just before the end of the video and Chrome was complaining that the last few chunks of data were corrupt. A recent update to Chrome must have changed something that made it more sensitive to the quality of a media file. While other browsers will contently play it without issue, Chrome throws its toys out the pram instead.
The video had been edited to be shorter (apparently there's a timelimit on how long we can watch kittens playing with a laser pen while testing Gorilla's systems) and the cut in the video hadn't been created cleanly by the editing software. It seems a common practice to trim sections from a video/audio, compress them, change their file format or process them in someway. So, in the first instance, always go back to the source material and see if you get the trouble there. If you don't, try the editing process again or try using another tool. If you haven't edited the media from source, see if your editing software has a validation tool that can be used to check for (and hopefully fix!) any corruption in the media.
Error message seen by participant: “Something has gone wrong while trying to download the media. Either the audio file is missing or your browser cannot play it. You can try refreshing the page but, if the problem persists, you'll need to report this issue to the researcher”
Error message seen by researcher: “The media resource indicated by the src attribute was either missing or not supported by the browser”
This error is a bit more... complicated and the docs on this are rather lacking. One half of it seems to be a similar issue to MEDIA_ERR_NETWORK, though the conditions under which this one fires rather than the other is unclear. The other half, not being supported by the browser, seems to come up with the media source is actually a media 'stream' rather than a file. Its not possible to populate an Audio or Video component from a media stream - stimuli need to uploaded in advance and you can't upload a stream!
This is an error for which I can't forsee a reason for it triggering in a Gorilla task. If we find a reason, we'll update this document accordingly.
Error message seen by participant: “No media element present: While trying to load the media, no containing media element could be found!”
Error message seen by researcher: “No media element present: While trying to load the media, no containing media element could be found!”
Even though Gorilla has been told there should be a video or audio component on the page, it can't find the corresponding HTML for it!
Coding tip: if all the code that follows hinges on X existing then, even if you can't possible imagine a way in which you could arrive at this point without X being there, check that it's there anyway. While it might seem pedantic and unnecessary, and lead to awkwardly worded paragraphs in a support doc, a simple if/else statement can save you bags of time. Otherwise, X will be the last thing you look at at the end of a very long and frustrating bug hunt.
If an Audio or Video component is placed on a screen, Gorilla will collect the HTML for that component and add it to the page, before running the scripts associated with that component. That script begins by collecting a reference to the HTML on the page, which can then be used to prepare it for playback and, eventually, trigger the play function! Can't trigger a play function on HTML that doesn't exist though, which is why checking it exists on the page is a necessary step.
Reaching the point of running a component's script but not actually have the component's HTML on the page is not something I've ever encountered in my (at the time of writing) fifteen months of supporting Gorilla users. I suppose, hypothetically, if something prevented or interrupted the HTML while it was rendered, but without disrupting any other functionality, then it's possible we could arrive at this eventuality.
Like all the errors above, the full content of the error will come direct to our servers too, so if this does ever occur, we should be able to work out why!
So, now that all this has been implemented, what will the Gorilla team do next?
We'll wait!
Honestly, that's the next thing to do. Now that we have all this error messaging in place, as soon as any error messages come in, we can start taking action. That action may only consist of updating this document with possible causes for the different errors and advice on how to handle them, which will hopefully be helpful. Ideally though, it will result in some new preventative systems being built into Gorilla, that will either prevent the error from occurring or warn the user much earlier that there is a potential problem.
