Actually, although we haven’t had a chance to get in an d fix the
reset() command, another user pointed out there is where you include a nameOfMovie.stop() in an End Routine Code Component. Easier (and less heavy on the download) than duplicating movies
Actually, although we haven’t had a chance to get in an d fix the
No I never got round to it; I shifted to an alternative for the time being. I will probably try again next time I have a project that needs it - it wouldn’t need much doing to get it finished.
Can you explain a bit more about this solution? I am having the same problem, and duplicating movies would mean I would need about 260 video files for participants.
If you have a movie component called myMovie then add a Code Component to your Routine with this in the End Routine code block:
Thanks for the reply, I have tried this, as well as adding nameOfMyMovie.play(); at the start routine block (tried with both .stop only, .play only and both, both works best):
Begin routine: movie.play();
End routine movie.stop();
This sort of changes things, however the videos now start sometimes in the middle, or sometimes at the start, and then play to the end, and then show the start again if they began in the middle. My movies runs for 3.75s
Is there anything I can add to make it start the video at 00ms?
That’s weird. movie.stop() should implicitly reset the movie as well.
There is also a seek function that you might be able to make use of:
Make sure you put that in a code component below the movie itself so that it does teh seek after loading the movie from file.
Yes. I have have been successfully using something similar as a workaround, until a fixed version of the Builder is available.
Assuming you have a movie called myMovie, add a single code component below it, with:
Begin routine: myMovie.play();
End routine: myMovie.seek(0);
This ensures that the movie resumes at its beginning on its next presentation. But has the limitation of requiring the movie to start only at the beginning of a trial, which may not allow enough time for the movie time to pre-load before its first presentation, leading to slight timing errors.
Couldn’t you do something like the following…?
Begin Routine moviestarted=0 Each Frame if t > .5 and moviestarted == 0: moviestarted = t myMovie.play() End Routine myMovie.stop() myMovie.seek(0)
@jon @d.govan @wakecarter
Thanks for the replies. Movie.seek(0) works great, as did the previous movie.stop - my issue turned out to be that I had ticked loop playback in one of my earlier attempts to get it to reset.
However, now it is failing to show some of the videos some times- they are all loaded and play when clicked on in the GitLab, and they also play when the experiment is run through psychopy. They also all seem to manage to play at some point during the run, there are just occasional blank sections where the video should be. The rest of the trial runs fine. If anyone has any ideas they would be greatly appreciated.
So, I don’t know why the problem was happening, but I fixed it by taking my videos out of their folder and just having them in the main folder - basically removing the need for a file path.
I have no idea why this worked, as it managed the play every video, just not every time, but problem solved! Thanks.
Spoke too soon, the issue is still there - just less frequent - basically it occasionally fails to show the video - but the trial continues as normal. All videos successfully play over the course of the study - so it isn’t an error with a specific video, and all trials are the same routine, so it isn’t a particular routine. The issue occurs both on Chrome and on Edge (I haven’t tried other browsers). Any ideas appreciated.
How big are the videos? Could it be a memory overload issue – could you try a lower resolution or higher compression?
Thanks for the reply, videos are about 754 KB … this shouldn’t be an issue on my machine, but if this might be an issue on others I should lower the resolution (let me know if you think this might be too high, though I plan to get a few people to test before I start recruiting).
I do seem to have fixed the issue though (this may be another spoke too soon, but I have done 2 full runs and it seems fine) my solution was to add a blank routine before the trial routine in the loop, this last 100ms, and then add a blank image at the start of my main trial routine which does nothing, and is ‘shown’ for 100ms. I am not sure which of these helps, or if it is both. Also, I don’t know why this might have worked!
Maybe it gives PsychoPy time to load the movie.
That sounds a bit like my earlier suggestion on this thread:
if t > .5 and moviestarted == 0: moviestarted = t myMovie.play()
That was the solution I eventually used to overcome one of the limitation of being able to present the movies at only the beginning of a trial. That is, I added a blank text inter-trial interval of a few seconds before the movie trial (within the trial loop), delaying the start of the movie (it works well where precise timing is not required).
I was using PsychoPy v2020.1.3 and I was not able to get .stop() working at all, the movies still remained static after their first presentation, hence substituting .seek(0) as the minimal solution.
I also had a series of movie clips with different run times, and I found that if I truncated their duration, then the remaining audio would continue to play to the end, after the movie had disappeared, even continuing after the end of the trial. The solution was to not specify duration for the movies, so that they always played to the end (collecting responses can also truncate trials early). To avoid this happening, a response collection routine can be added just after the movie trial, inside the trial loop (with the ITI mentioned above; again it works well where precise timing is not required).
Thanks for the tips!
After further experimentation, and for completeness, I will add this additional finding:
Only if a trial finishes before the end of the movie or the movie is set to loop, then the movie’s sound will continue to play until finished or will loop until the end of the experiment, which is far from ideal. The solution to this problem is to use a Code component as described above, and then adding myMovie.stop() just above myMovie.seek(0) under the End Routine tab (the .stop() is not necessary if the end of the movie also ends the trial, or the movie does not either have or play an audio track). Evidently, a movie’s sound is stopped automatically only when the end of the movie triggers the end of the trial.
Again, hopefully these workarounds will become unnecessary soon, with newer versions of the Builder.
gitlab experiment: https://gitlab.pavlovia.org/mmemeo/test_intentions
I’m having the same issue you experienced: the videos are not refreshing after each trials but they seem to be frozen at the frame in which participants press a button.
I need my participants to answer while the video is playing. I read all your helpful comments and the final version of Code Component I used is:
moviestarted = 0
if t > .05 and moviestarted == 0: moviestarted = t myMovie.play() for key in event.getKeys(): if key in ['p','d']: continueRoutine = False
I wonder what I’m doing wrong and I really hope you can help me.
Thanks a lot!
Maybe try this post for a specific fix for Chrome:
I solved similar problems I had when playing videos for a second time by combining some of the approaches mentioned in this thread and in others:
(the one supposed to play the video for the second time)
myMovie._movie.currentTime = 0; myMovie.play();
I also posted this in the thread Videos are not played multiple times in Pavlovia
A note on the video solution to use movie.play() in the code component.
Because this goes in ‘begin routine’, it seems to start the video as soon as the routine starts whether it is onscreen or not - i.e. you may not want it to play until after a 1second fixation. so set it to start at 1, however the video will actually have already been playing for 1 second before it actually appears.
This issue has made all my timings completely wrong, and so I hope others see this and don’t make the same mistake.
To resolve I have put the fixation in a separate routine.