|
AKrishna
|
|
|
Group: Forum Members
Posts: 88,
Visits: 266
|
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.
|
|
|
|
|
AKrishna
|
|
|
Group: Forum Members
Posts: 88,
Visits: 266
|
+xHi 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
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 12K,
Visits: 98K
|
+x+xHi 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/7facIt 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.
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 12K,
Visits: 98K
|
+x+x+xHi 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/7facIt 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.
|
|
|
|
|
AKrishna
|
|
|
Group: Forum Members
Posts: 88,
Visits: 266
|
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!
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 12K,
Visits: 98K
|
+xSorry 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.
|
|
|
|
|
AKrishna
|
|
|
Group: Forum Members
Posts: 88,
Visits: 266
|
+x+xSorry 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.
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 12K,
Visits: 98K
|
+x+x+xSorry 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.
|
|
|
|
|
AKrishna
|
|
|
Group: Forum Members
Posts: 88,
Visits: 266
|
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.
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 12K,
Visits: 98K
|
+xSpeculation 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.
|
|
|
|