Running with --video where the video would need to be overwritten silently stalls browsertime (macOS)

[acreskeyMoz]

When running a test where the video recording already exists (and would need to be overwritten), I'm seeing browsertime silently stall after issuing the ffmpeg video command. (macOS).

If I delete the previously-made video, the new recording will be made and the test will proceed.

For instance, here's an example ffmpeg command:

[2021-04-30 16:25:37] DEBUG: [browsertime.video] Start FFMPEG with ["-f","avfoundation","-i","2","-r",30,"-filter:v","crop=2732:1536:0:0","-codec:v","libx264rgb","-threads",0,"-crf","0","-preset","ultrafast","/Users/acreskey/tools/browsertime/responsiveness/browsertime-results/facebook/firefox/x11-tmp.mp4"]

If I run that from the terminal, I see the prompt: Overwrite ? [y/N]

It looks like adding the ffmpeg option, -y will force an overwrite.
@dpalmeiro, who helped me debug this, raised the possibility that a timeout could be added.

Here's my browsertime command:

./browsertime/bin/browsertime.js --skipHar --videoParams.addTimer false --videoParams.createFilmstrip false --videoParams.framerate 60 --video true --visualMetrics true  --firefox.windowRecorder false --visualMetricsContentful -n 1  --verbose --resultDir  browsertime-results/facebook/firefox -b firefox tests/facebook.js

Where the test is simply:

module.exports = async function(context, commands) {
return commands.measure.start('https://www.facebook.com/');
}

[soulgalore]

Hi @acreskeyMoz ok, let me fix that. Need to check though, I wonder if the other result files are overwritten by default?

[soulgalore]

Hmm.I cannot reproduce it. That file x11-tmp.mp4 is the temporary file that should be removed between runs, that is strange. If you empty the dir @acreskeyMoz and do one run, do you have that temporary file?

[acreskeyMoz]

Thanks for looking at this @soulgalore .

I think I found out what was happening:
I must have been interrupting my runs (e.g. through Ctrl-C), and I just confirmed that in this case the file x11-tmp.mp4 will be left behind, thus stalling the next run.

Outside of the user aborting the test, I haven't been able to reproduce this.

[acreskeyMoz]

Ah, some test errors will also leave the residual temp file, x11-tmp.mp4

e.g.

[2021-05-05 14:33:40] DEBUG: [browsertime.video] Started ffmpeg with -f avfoundation -i 2 -r 30 -filter:v crop=2732:1536:0:0 -codec:v libx264rgb -threads 0 -crf 0 -preset ultrafast /Users/acreskey/tools/browsertime/responsiveness/browsertime-results/change_color/firefox/x11-tmp.mp4
[2021-05-05 14:33:40] DEBUG: [browsertime.command.measure] Mark run as failure with message Unable to locate element: /html/body/div[1]/button[2]
[2021-05-05 14:33:40] ERROR: [browsertime] NoSuchElementError: Unable to locate element: /html/body/div[1]/button[2]
    at Object.throwDecodedError (/Users/acreskey/tools/browsertime/responsiveness/browsertime/node_modules/selenium-webdriver/lib/error.js:517:15)

[soulgalore]

One way to hack this could be to generate random file names for temp files, but it's on a couple places that needs to happen. In the old days we used the tmp dir from the OS but we had people reporting that they didn't have write privileges to that dir (!). Maybe adding a timestamp to the tmp-file would fix this for now.