Skip to content

Add a delay mid stream

A broadcast delay puts distance between what you do and what your viewers see. It is the standard answer to stream sniping, and it buys you a few seconds to react when something is about to be on camera that should not be.

Everywhere else, adding a delay means ending your stream, changing a setting, and starting again. OBS documents this plainly: a delay change “will only affect the next time the output is activated”. Pyre applies a delay while you are live.

When you apply a delay, your studio immediately covers the stream with your delay card and starts holding your footage behind it. The card carries a countdown for the whole wait, so viewers know what they are waiting for. When the countdown reaches zero the card lifts and your viewers are watching your stream, now the chosen number of seconds behind.

Turning a delay on never interrupts your stream. Your platform connections are never restarted, so you keep your session, your viewer count and your went live notification.

The card is drawn from the same library as your reconnect card, so a delay looks like your channel rather than like a piece of software.

  1. Open Delay in the Pyre.Stream sidebar, or use the Add delay tile in the Stream Manager while you are live.

  2. Choose a length. There are presets for 30 seconds, 2, 5, 10 and 15 minutes, and a field for anything else up to an hour.

  3. Confirm. The card appears within a couple of seconds, and lifts when the buffer is full.

The Delay page shows what your studio has actually confirmed, never the number you just typed. If your studio has not reported back, you get Saved. Waiting for your studio to pick it up. where the running delay would be.

That is not an error. Your setting is stored and it takes effect the moment the studio in your path picks it up. If it stays there, the studio is behind the feature: a desktop app that has not been updated, or a Cloud Studio pod still running an older image.

Increasing a delay shows the card again, but only for the difference. Going from 30 seconds to 2 minutes shows the card for the extra 90 seconds while the buffer fills behind it, then lifts.

Removing a delay skips your viewers forward, because there is no way to fast forward a live stream. Whatever was still held is never seen. Pyre asks you to confirm and names the exact number of seconds your viewers will lose, on the confirm button as well as in the question, because a warning without a number is a dialog people click through.

Your stream is held on disk before it is sent anywhere: on your own computer with Desktop Studio, on your pod with Cloud Studio. A 2 minute delay holds about 0.12 GB, and an hour holds about 3.6 GB.

Pyre checks there is room before it starts, and refuses with the real numbers if there is not, naming what the delay needs and what the drive actually has free. It never silently gives you a shorter delay than you asked for.

With a delay running, your studio keeps sending held footage while a source is missing. A dropout shorter than your delay is invisible to your viewers: a 20 second dropout under a 30 second delay is simply not seen. A delay is a shock absorber as well as a snipe guard.

When that happens the delay chip shows what you now actually have, for example 0:10 of 0:30, and offers Rebuild in one click. Pyre tells you rather than quietly repairing it, because a snipe guard that silently got weaker is worse than one that says so.

Ending your stream plays out the remaining delay so viewers see your ending. The chip counts the drain down, and Cut now is there if you would rather not wait.

In the desktop app, quitting while footage is still draining asks first and tells you how much is left, because closing Pyre at that moment cuts your viewers off mid sentence.