Troubleshooting Connection Issues
Our Desktop Recording Client works by streaming data in real-time over WSS (secure web sockets) to a media server hosted by us towards port 443.
The connection is established as soon as the user presses [Record Video], [Record Audio], or [Record Screen] on the initial screen.
Reconnection Mechanism
In case of a network problem resulting in disconnection, the Desktop Recording Client will try to reconnect 30 times before giving up.
Each of the 30 attempts to reconnect can timeout after 10 seconds. After each timeout or failed re-connection attempt, the recorder will wait between 0.5 and 5 seconds before making another attempt. Thus, it can take a maximum of 450 seconds ((10s timeout + 5s delay) * 30 attempts = 450 seconds = 7.5 minutes) for the recorder to spend all 30 attempts. This interval can be even higher if there’s anything blocking the JavaScript client side.
If a disconnection happens while recording, the recording process will continue, but a message will be shown to the user. If the connection is re-established, the data recorded while the connection was interrupted will start uploading to the media server while the recording process continues.
Why an established WebSocket connection might disconnect:
- A busy or high latency WiFi network might cause continuously open wss connections to disconnect.
- The Internet connection might fail (ISP problems, power failure, tripping over the router, etc.).
- Conditions on the network (proxy, firewall) have changed not allowing WebSockets connections anymore.
Connection Error messages
In case of a connection problem, the HTML5 desktop recorder will show one of the following messages:
Not Connected. Reconnecting in a few seconds
This message is shown when the first connection attempt ever to the media server fails.
Not Connected (wss). Reconnecting in a few seconds
This message is shown when a subsequent (re)connection attempt to the media server fails.
Connection timeout. Reconnecting in a few seconds…
This message is shown when a connection attempt times out after 10 seconds.
Not Connected. Reconnecting…
This message is shown when Pipe attempts to connect or reconnect. If the connection attempt fails right away, this message is shown for a fraction of a second. If the connection attempt fails through a time out, this message will be shown for the duration of the timeout (10 seconds).
Reconnected
Shown for a moment after a successful reconnect attempt.
Your connection to the server has been interrupted
This is meessage is shown when all 30 attempts to re-connect are unsuccessful.
Causes:
- The user is disconnected from the Internet (ISP problems, power failure, tripping over the router, etc.)
- The media server might be down or have no Internet connection
Recovering Unsaved Recordings
For recordings made with our Desktop Recording Client by capturing from the camera or screen, the ingestion media servers have a recording recovery mechanism in place that recovers the recording if, while streaming the recording (so while recording or uploading it), the connection is interrupted, and a new connection can’t be established. This mechanism is triggered only if the autosave option is enabled in the embed code (by default, it is enabled).
Desktop Recording Client
Recordings made by capturing from the camera or screen and streaming back to our ingestion servers
In case of a network problem resulting in disconnection, the Desktop Recording Client will try to reconnect 30 times before giving up. As shown above, this process can take up to 450 seconds and even more. That’s why the ingestion media server, under normal circumstances, will wait 15 minutes - from the moment the disconnection is detected server-side - before attempting to recover an unsaved recording. It needs to give the user all the time it needs to cycle through his 30 reconnect attempts.
Recordings made by uploading an existing recording
The recovery mechanism does not function with existing recordings uploaded through the desktop recording client.
Mobile Native Recording Client
Recordings made by uploading an existing recording
The recovery mechanism does not function with new or existing recordings uploaded through the Mobile Native Recording Client.
Using webhooks instead of the JS Events API
We recommend relying on Webhooks for integrating the Pipe Recording Client instead of relying on the JavaScript APIs because webhooks will trigger for recovered recordings.
When a disconnection is the result of the user navigating away, closing the tab, browser crash, or the window/tab being accidentally closed, the JS API events will not trigger. As a result, your JS functions will not trigger and any POST or GET requests (made within your JS) back to your server (to save the data) will never trigger. If the recording is recovered, webhooks will be triggered.
When the disconnection results from a network connection problem like a high latency connection, the JS will execute on the client, but any POST or GET requests might fail. If the recording is recovered, webhooks will be triggered.