A call to vid:set-time before vid:start or vid:stop ruins the player

After opening a movie file, the first command should be vid:start or vid:stop. This initialization makes the player 'ready' for the set-time command and works flawlessly from then. However, if you feed vid:set-time as the first command after loading, the subsequent start and stop commands do not work as expected (start does not play the video, and stop 'teleports' the video according to the elapsed time without showing the progress).

Edit: programmatically calling start or stop right after opening the video does not fix the problem. It needs at least two iterations (such as start and then stop) before the 'initialization' happens, and there needs to be a little bit of wait (about 1 second) between them in order to make the workaround functional. It seems like the actual 'playing action' is needed to gain immunity against this set-time related bug.

Tested in Windows 10, NetLogo 6.2.2.

The payload names no files, tests, or entry points. Reproduce the command sequence after opening a movie—vid:set-time followed by vid:start and vid:stop—and trace the player initialization behavior. Done means set-time can be the first command and later start and stop work correctly without waiting or extra commands.