Millisecond Forums

Online experiment crashes on video load

https://forums.millisecond.com/Topic34706.aspx

By AKrishna - 9/8/2022

Hi all, an odd one today...

An online experiment (registered under my username in the EU region, named AOPA) is crashing for no discernable reason with no error log. Specifically, after the first two files in the batch are run (informed consent and demographics), the main experiment starts. The first block (testing whether participants can see and hear video) runs without issue, including the test video. Then, the experiment asks several attitude items before showing another video. However, in most (but not all) cases, Inquisit quits to desktop when the video file should be played, with no error logged.

I had thought that the problem occurs due to the dynamic selection of the video stimulus from the second block on (it's done via clearing the /items property of the video element, then appending an item pointing to the video file whose name is constructed from various conditions), but the code runs fine offline and my online debugging shows that the filename is being correctly constructed. The videos are all uploaded as well. Could there be some limitation with the video item filenames that only applies online?

I'll continue testing myself, but I would appreciate any input, as I get the feeling that this might be something in the backend that I don't have access to.
By AKrishna - 9/8/2022

AKrishna - 9/8/2022
Hi all, an odd one today...

An online experiment (registered under my username in the EU region, named AOPA) is crashing for no discernable reason with no error log. Specifically, after the first two files in the batch are run (informed consent and demographics), the main experiment starts. The first block (testing whether participants can see and hear video) runs without issue, including the test video. Then, the experiment asks several attitude items before showing another video. However, in most (but not all) cases, Inquisit quits to desktop when the video file should be played, with no error logged.

I had thought that the problem occurs due to the dynamic selection of the video stimulus from the second block on (it's done via clearing the /items property of the video element, then appending an item pointing to the video file whose name is constructed from various conditions), but the code runs fine offline and my online debugging shows that the filename is being correctly constructed. The videos are all uploaded as well. Could there be some limitation with the video item filenames that only applies online?

I'll continue testing myself, but I would appreciate any input, as I get the feeling that this might be something in the backend that I don't have access to.

OK, it appears to be running now, although I can't easily iterate and check whether every condition works. However, some videos that apparently consistently crashed the program now run after I reduced the length of their filenames.

Is there any reason why item names like "videoname.mp4" would not function on Inquisit Web if they are longer than about 28 characters? Could the web server be truncating filenames over 24 characters (not counting the .mp4 extension)? This would explain the error and put any fears that individual videos might not work to rest. This would also be consistent with Inquisit's behavior: the program also crashed without an error message when confronted with a filename that didn't exist, but had been assigned as a video item. So if my past version was trying to access the videos using the full file names, but the files on the server had truncated names, that would explain my observed issue. Would appreciate confirmation so I can be reasonably sure the experiment will run for all videos
By Dave - 9/8/2022

AKrishna - 9/8/2022
AKrishna - 9/8/2022
Hi all, an odd one today...

An online experiment (registered under my username in the EU region, named AOPA) is crashing for no discernable reason with no error log. Specifically, after the first two files in the batch are run (informed consent and demographics), the main experiment starts. The first block (testing whether participants can see and hear video) runs without issue, including the test video. Then, the experiment asks several attitude items before showing another video. However, in most (but not all) cases, Inquisit quits to desktop when the video file should be played, with no error logged.

I had thought that the problem occurs due to the dynamic selection of the video stimulus from the second block on (it's done via clearing the /items property of the video element, then appending an item pointing to the video file whose name is constructed from various conditions), but the code runs fine offline and my online debugging shows that the filename is being correctly constructed. The videos are all uploaded as well. Could there be some limitation with the video item filenames that only applies online?

I'll continue testing myself, but I would appreciate any input, as I get the feeling that this might be something in the backend that I don't have access to.

OK, it appears to be running now, although I can't easily iterate and check whether every condition works. However, some videos that apparently consistently crashed the program now run after I reduced the length of their filenames.

Is there any reason why item names like "videoname.mp4" would not function on Inquisit Web if they are longer than about 28 characters? Could the web server be truncating filenames over 24 characters (not counting the .mp4 extension)? This would explain the error and put any fears that individual videos might not work to rest. This would also be consistent with Inquisit's behavior: the program also crashed without an error message when confronted with a filename that didn't exist, but had been assigned as a video item. So if my past version was trying to access the videos using the full file names, but the files on the server had truncated names, that would explain my observed issue. Would appreciate confirmation so I can be reasonably sure the experiment will run for all videos

Does this run for you?

https://mili2nd.eu/7fac

It plays a single video, and the file name is 0123456789_0123456789_0123456789.mp4 (32 characters plus the .mp4 extension). Works perfectly fine for me, so I don't believe length is the determining factor here.
By Dave - 9/8/2022

Dave - 9/8/2022
AKrishna - 9/8/2022
AKrishna - 9/8/2022
Hi all, an odd one today...

An online experiment (registered under my username in the EU region, named AOPA) is crashing for no discernable reason with no error log. Specifically, after the first two files in the batch are run (informed consent and demographics), the main experiment starts. The first block (testing whether participants can see and hear video) runs without issue, including the test video. Then, the experiment asks several attitude items before showing another video. However, in most (but not all) cases, Inquisit quits to desktop when the video file should be played, with no error logged.

I had thought that the problem occurs due to the dynamic selection of the video stimulus from the second block on (it's done via clearing the /items property of the video element, then appending an item pointing to the video file whose name is constructed from various conditions), but the code runs fine offline and my online debugging shows that the filename is being correctly constructed. The videos are all uploaded as well. Could there be some limitation with the video item filenames that only applies online?

I'll continue testing myself, but I would appreciate any input, as I get the feeling that this might be something in the backend that I don't have access to.

OK, it appears to be running now, although I can't easily iterate and check whether every condition works. However, some videos that apparently consistently crashed the program now run after I reduced the length of their filenames.

Is there any reason why item names like "videoname.mp4" would not function on Inquisit Web if they are longer than about 28 characters? Could the web server be truncating filenames over 24 characters (not counting the .mp4 extension)? This would explain the error and put any fears that individual videos might not work to rest. This would also be consistent with Inquisit's behavior: the program also crashed without an error message when confronted with a filename that didn't exist, but had been assigned as a video item. So if my past version was trying to access the videos using the full file names, but the files on the server had truncated names, that would explain my observed issue. Would appreciate confirmation so I can be reasonably sure the experiment will run for all videos

Does this run for you?

https://mili2nd.eu/7fac

It plays a single video, and the file name is 0123456789_0123456789_0123456789.mp4 (32 characters plus the .mp4 extension). Works perfectly fine for me, so I don't believe length is the determining factor here.

Here's another one, with file names constructed on the fly, up to a length of 65 characters (plus extension), to more closely mimic your script's construction logic:

https://mili2nd.eu/agac

<block myblock>
/ trials = [1-4=mytrial]
</block>

<values>
/ fname = "0123456789_0123456789"
</values>

<trial mytrial>
/ ontrialbegin = [
    video.myvideo.clearitems();
    values.fname = concat(values.fname, "_0123456789");
    video.myvideo.appenditem(concat(values.fname, ".mp4"));
]
/ stimulusframes = [1=myvideo]
/ validresponse = (57)
</trial>

<video myvideo>
/ items = ("0123456789_0123456789_0123456789_0123456789_0123456789_0123456789.mp4")
</video>

<video load>
/ items = myitems
</video>

<item myitems>
/ 1 = "0123456789_0123456789_0123456789.mp4"
/ 2 = "0123456789_0123456789_0123456789_0123456789.mp4"
/ 3 = "0123456789_0123456789_0123456789_0123456789_0123456789.mp4"
/ 4 = "0123456789_0123456789_0123456789_0123456789_0123456789_0123456789.mp4"
</item>


This also works perfectly fine for me.
By AKrishna - 9/9/2022

Sorry for the delay, was away from my work computer (where I got the error). Interestingly, both of your scripts work fine for me. Really not sure what could have been the problem on the old version of my project... Thanks for looking into thsi!
By Dave - 9/9/2022

AKrishna - 9/9/2022
Sorry for the delay, was away from my work computer (where I got the error). Interestingly, both of your scripts work fine for me. Really not sure what could have been the problem on the old version of my project... Thanks for looking into thsi!

I would suspect a perhaps very subtle mistake in the file name construction logic (a stray space in some of the constructed file names?) in the old version that was fixed in the process of shortening the file name components, but I cannot be sure.
By AKrishna - 9/9/2022

Dave - 9/9/2022
AKrishna - 9/9/2022
Sorry for the delay, was away from my work computer (where I got the error). Interestingly, both of your scripts work fine for me. Really not sure what could have been the problem on the old version of my project... Thanks for looking into thsi!

I would suspect a perhaps very subtle mistake in the file name construction logic (a stray space in some of the constructed file names?) in the old version that was fixed in the process of shortening the file name components, but I cannot be sure.

Normally, I would agree - but I tested the exact same file offline with the exact same video files and it worked. The literal only difference between a working version and one that crashed on loading some videos was that the files were uploaded and running via Inquisit Web instead of on my own computer.
By Dave - 9/9/2022

AKrishna - 9/9/2022
Dave - 9/9/2022
AKrishna - 9/9/2022
Sorry for the delay, was away from my work computer (where I got the error). Interestingly, both of your scripts work fine for me. Really not sure what could have been the problem on the old version of my project... Thanks for looking into thsi!

I would suspect a perhaps very subtle mistake in the file name construction logic (a stray space in some of the constructed file names?) in the old version that was fixed in the process of shortening the file name components, but I cannot be sure.

Normally, I would agree - but I tested the exact same file offline with the exact same video files and it worked. The literal only difference between a working version and one that crashed on loading some videos was that the files were uploaded and running via Inquisit Web instead of on my own computer.

No idea then; it doesn't really make sense and the server definitely does not truncate file names or anything like that. The only thing it does is change file names to all-lowercase characters during upload to the server, for reasons of cross-platform compatibility. That, however, should not have played any role here.
By AKrishna - 9/9/2022

Speculation here, but maybe it has something to do with how the files are named when they are downloaded at the start of the experiment? My stimulus sets were long and shared large portions of their names. It would be very weird regardless, and I'm not sure why the problem didn't occur on the same computer with your scripts (especially the second one).

If it's a client-side thing, well... there isn't much that can be done if I can't reproduce it consistently. I'm under pressure to run the experiment, so I will probably just do it with the shorter filenames and hope there's no crashes, but if desired, I can recreate and upload an older version of the same experiment so we can try to reproduce it. Might be a few days before I have time, though.
By Dave - 9/9/2022

AKrishna - 9/9/2022
Speculation here, but maybe it has something to do with how the files are named when they are downloaded at the start of the experiment? My stimulus sets were long and shared large portions of their names. It would be very weird regardless, and I'm not sure why the problem didn't occur on the same computer with your scripts (especially the second one).

If it's a client-side thing, well... there isn't much that can be done if I can't reproduce it consistently. I'm under pressure to run the experiment, so I will probably just do it with the shorter filenames and hope there's no crashes, but if desired, I can recreate and upload an older version of the same experiment so we can try to reproduce it. Might be a few days before I have time, though.

> Speculation here, but maybe it has something to do with how the files are named when they are downloaded at the start of the experiment?

I don't see how that could be the case; to be sure, Windows used to have some weird constraints on maximum local path length, but these are a thing of the past and, in any event, the 2nd test script I posted should have triggered the error if that were the problem.

> I can recreate and upload an older version of the same experiment so we can try to reproduce it. Might be a few days before I have time, though.

I'll be happy to take a look if you want to go for this. It would, however, be important to have the exact script (and associated files) that originally produced the error, not a recreation. If that script had some really subtle mistake in it, the recreation might not have it.
By AKrishna - 9/9/2022

Dave - 9/9/2022
AKrishna - 9/9/2022
Speculation here, but maybe it has something to do with how the files are named when they are downloaded at the start of the experiment? My stimulus sets were long and shared large portions of their names. It would be very weird regardless, and I'm not sure why the problem didn't occur on the same computer with your scripts (especially the second one).

If it's a client-side thing, well... there isn't much that can be done if I can't reproduce it consistently. I'm under pressure to run the experiment, so I will probably just do it with the shorter filenames and hope there's no crashes, but if desired, I can recreate and upload an older version of the same experiment so we can try to reproduce it. Might be a few days before I have time, though.

> Speculation here, but maybe it has something to do with how the files are named when they are downloaded at the start of the experiment?

I don't see how that could be the case; to be sure, Windows used to have some weird constraints on maximum local path length, but these are a thing of the past and, in any event, the 2nd test script I posted should have triggered the error if that were the problem.

> I can recreate and upload an older version of the same experiment so we can try to reproduce it. Might be a few days before I have time, though.

I'll be happy to take a look if you want to go for this. It would, however, be important to have the exact script (and associated files) that originally produced the error, not a recreation. If that script had some really subtle mistake in it, the recreation might not have it.

Agreed. Unfortunately, I actually overwrote the old script files and renamed the original video files in my haste to figure out a solution to the problem. I'll tell you what - when I have some time (hopefully next week), I'll try and see whether I can reconstruct the file from older versions and see whether I can get the same error on my workstation. If so, I'll let you know. If not, it'll have to remain an unsolved mystery, I guess.
By Dave - 9/9/2022

AKrishna - 9/9/2022
Dave - 9/9/2022
AKrishna - 9/9/2022
Speculation here, but maybe it has something to do with how the files are named when they are downloaded at the start of the experiment? My stimulus sets were long and shared large portions of their names. It would be very weird regardless, and I'm not sure why the problem didn't occur on the same computer with your scripts (especially the second one).

If it's a client-side thing, well... there isn't much that can be done if I can't reproduce it consistently. I'm under pressure to run the experiment, so I will probably just do it with the shorter filenames and hope there's no crashes, but if desired, I can recreate and upload an older version of the same experiment so we can try to reproduce it. Might be a few days before I have time, though.

> Speculation here, but maybe it has something to do with how the files are named when they are downloaded at the start of the experiment?

I don't see how that could be the case; to be sure, Windows used to have some weird constraints on maximum local path length, but these are a thing of the past and, in any event, the 2nd test script I posted should have triggered the error if that were the problem.

> I can recreate and upload an older version of the same experiment so we can try to reproduce it. Might be a few days before I have time, though.

I'll be happy to take a look if you want to go for this. It would, however, be important to have the exact script (and associated files) that originally produced the error, not a recreation. If that script had some really subtle mistake in it, the recreation might not have it.

Agreed. Unfortunately, I actually overwrote the old script files and renamed the original video files in my haste to figure out a solution to the problem. I'll tell you what - when I have some time (hopefully next week), I'll try and see whether I can reconstruct the file from older versions and see whether I can get the same error on my workstation. If so, I'll let you know. If not, it'll have to remain an unsolved mystery, I guess.

Alright, sounds like a plan. I'll keep my eyes on this thread for any updates.