Record Through Unstable Connections - New Reconnect Mechanism in the HTML5 Recorder

We’ve added a reconnection mechanism to the desktop HTML5 recorder.

Until now, when the connection to the media server was lost, an error message was shown (Your connection to the server has been interrupted) and that was it. You would have had to reload the page in order to record again. This was problematic especially if a recording was is in progress.

So we set out to improve this experience. After a couple of iterations, we managed to implement the best case scenario solution: a reconnection mechanism that works behind the scenes even while the user is recording.

The New Reconnect Mechanism in the HTML5 Recorder

The biggest improvement is that you can continue your recording while you’re temporarily disconnected from our media server or from the WiFi or if the Internet connection is lost altogether. What you record while disconnected is saved in a local buffer. Once the connection is reestablished the data in the buffer will be uploaded to our media server in the order it was recorded.

But how exactly does it work?

When a disconnection is detected the reconnect mechanism will spring into action making a total of 30 attempts to reconnect to the server before failing completely. The 1st attempt will be made using web sockets while the next 29 will be made using long pooling https requests. After each attempt, there will be a 1 - 1.5 0.5 – 5 seconds waiting time. The entire retry mechanism will thus take about 45 seconds before giving up.

Not all disconnections are detected right away. Try suddenly pulling your ethernet cable and the recorder will take up to 10 seconds to detect the problem.

A reconnection attempt can have 2 outcomes:

• the attempt fails, in which case a specific reconnect error message is shown at the top of the screen and another attempt is made in 1 - 1.5 0.5 - 5 seconds
• the attempt is successful, in which case a reconnect success message is shown at the top of the screen

Here is how and where these messages will be shown. We’ve tried to keep them low profile to prevent the user – who might be recording – from being distracted by them:

If all of the 30 reconnection attempts fail we consider the user is completely disconnected from the Internet and we show the final “Your connection to the server has been interrupted” message. In a basic implementation, the user will have to refresh the page to record again.

For the full list of messages shown and more information about the cases in which they are shown see the updated documentation.

All these new states for the connection can also be monitored – or hooked into – with the help of the updated onConnectionStatus event function part of the JS Events API. Its documentation has been updated too.

Updated Video Recovery Mechanism

This feature also has effects on the recording recovery mechanism. Fewer videos will have to be recovered due to connections being reestablished and recordings continued.

We've also introduced a 60 seconds delay in recovering a video because the user has 30 chances to reconnect which will span for about 45 seconds.

Recovered recordings have an (R) beside them in the Pipe account area:

Update 6th of December 2019

Recording over very slow connections some times caused multiple disconnects and reconnects and intervals as high as 60 seconds in which no data was being sent to the server. This triggered the recovery mechanism to spring into action even though the recording was still uploading.

We've increased the recovery mechanism delay from 60 seconds to 180 seconds to avoid such issues.

Update 19th of April 2021
We've recently increased the recovery mechanism delay from 180 seconds to roughly 15 minutes, more details in the documentation.