Pipe changelog addpipe.com

New

Improvement

Until recently, the webhook data was sent only as application/x-www-form-urlencoded.

Now you can choose between sending the data the old way as application/x-www-form-urlencoded OR the new way as application/json.

All new webhooks will default to application/json.

All existing webhooks will continue to be sent as application/x-www-form-urlencoded, unless you choose to change them.

The content type of the webhook will be reflected in the schedule and logs pages of the webhooks section. Also, the webhook simulator will allow you to test the webhook with both content types.

Fix

Until now, if the Pipe desktop recording client was removed from the DOM before hitting the maximum recording limit, the recording simply continued forever until the user left or closed the webpage on which the Pipe recording client was embedded on.

The issue has been fixed today when we rolled out new, updated client side (pipe.js) files.

This only occurred when the Pipe recording client was removed using custom JS code. Removing the Pipe recorder with the built in remove function worked as expected and is the recommended way to remove Pipe from a webpage.

Improvement

Whether you're trying to:

• upload existing recordings through our desktop recorder
• upload recordings through the mobile native recording client
• POST them directly to our private POST API

we have a new slightly raised size limit for the files.

The limit is now 1GiB which is 1024 * 1024 * 1024 = 1.073.741.824 bytes.

Previously, the limit was 1000 MiB which is 1000 * 1024 * 1024 bytes.

The new higher limit means any file shown as 1GB on Linux and macOS (1.000.000.000 bytes) and any file shown as 1GB on Windows (1.073.741.824 bytes) will be accepted by our servers.

Fix

If your S3 bucket had a dot in the name, the URLs (url, rawRecordingUrl, snaptshotUrl, filmstripUrl) sent through the video_copied_s3 webhook would be incorrect as they missed the bucket name. This happened across storage services, regardless if you used S3 buckets from AWS or S3 API compatible storage.

Fix

Our mechanism that recovers recordings if the user is completely disconnected has been updated to recover the recordings after 15 minutes.

This has been done because our 30 reconnections attempts from the client side can, in theory, take just a bit longer than 12 minutes.

The documentation has been updated with more details.

The rollout of this new mechanism has been completed today across all our regions.

Fix

Today we've reduced the webhook timeout from 127 seconds to 30 seconds to prevent our virtual workers from being tied up in waiting for responses.

This change should not affect any integration dependent on webhooks as 30 seconds is more than enough to open a TCP connection and POST the tiny amount of data. Also, the platform is not dependent on the response, we just save the status, headers and body to the db, show them in the webhook logs section and delete them a month later.

Improvement

We've added the .3g2 extension to our list of extensions that are allowed when uploading from a mobile device using the mobile native recorder or when uploading directly from the desktop.

Here is a list of all the supported extensions (bolded is new):

Improvement

This round of changes focuses on one thing in particular: the way we add tasks for our transcoding servers.

Until now, the recording servers relied on the database to pass on the task needed to be done towards the transcoding servers.

With this update, we've implemented direct communication between the recording servers and the transcoding servers.

What does this mean for you?

• Faster processing (up to 150 ms faster )
• No more rare random delays (up to 2 minutes) in processing the recordings.

Stay tuned for the next round of updates for our recording servers!

Fix

Until today, some visitors using IPv6 might have had issues loading the Pipe Recorder. Those days are gone!

In situations where the user was connecting through IPv6 to a proxy and then to our client delivery server or CDN the X-Forwarded-For header contained IPv6 value which led to a 500 HTTP error instead of a proper JSON response. Parsing the header value (which lead to the error) only happened when the environment's region was set to Auto or Auto-US. From our investigation, this was a rare event. During the past month, it has affected under 100 requests against our precheck mechanism.

This also happened when the X-Forwarded-For header contained malformed information in which case we now just default to the eu region (when the region option is set to Auto on the environment) or us1 (Auto-US).

This is yet another improvement in a series of infrastructure improvements that we're making to the Pipe Platform.

Fix

The recording ID within a webhook payload was correctly sent as an Integer data type when the recording was processed in real-time (first attempt), but incorrectly sent as a String data type when the webhook was sent as a result of a successfully retried recording (one that failed on its first attempt).

This has been fixed so that the recording ID within any of the possible webhook payloads will always be an Integer data type across the board as it should.