Schedule a prerecorded live stream
Planning a prerecorded live stream that runs without you
Choose the source, timezone, recurrence pattern and playlist behaviour for an unattended prerecorded broadcast — and the failure shapes to check before the first occurrence.
Published
Updated
9 min read
- Written by
- DynTube Editorial
- Technically reviewed by
- DynTube Engineering
A schedule is a promise you make in advance and are not present to keep. You pick videos you already host, tell DynTube which timezone the broadcast belongs to, and choose between a single dated run and a repeating pattern. From then on the platform starts the stream at each occurrence with nobody in the room.
That is worth planning properly, because the failures are quiet. A schedule that will not run does not usually crash — it simply produces no broadcast, at a time when the people who care are already watching an empty page. Most of that risk is removed by deciding four things before you build anything: the source, the shape, the timezone and the playlist behaviour.
Decide the source: what is actually schedulable
A scheduled item has to be a video in your own DynTube library. Three conditions apply to every item, and all three are checked when you save the schedule rather than when the broadcast is due.
- It belongs to your account. A video from another account is refused.
- It is published. A draft or a still-processing upload is refused, and the rejection names the video.
- It has a playable rendition your plan entitles — HLS or MP4. If neither is available for that item, the schedule is not accepted.
Two consequences are easy to miss when planning a series. Selecting the same video more than once does not give you two plays of it: repeated selections are collapsed to a single entry, so build repetition with the repeat control rather than by listing the item twice. And external video URLs are not a supported source — schedules play what you host, so anything you want in a broadcast has to be uploaded and published first.
One more eligibility rule sits above the videos: a schedule attaches to a live stream on the current live system. A stream still running on the legacy system cannot take one, so if a schedule is part of the plan, create the stream on the current system from the start rather than discovering the refusal later.
Decide the shape: one dated run, or a pattern
The two schedule types are mutually exclusive by design, and the platform refuses the mixture rather than guessing.
| Decision | One-time | Recurring |
|---|---|---|
| Timing input | A single dated start time | A repeating pattern plus a start date |
| The other input | A repeating pattern is rejected | A single start time is rejected |
| End of the series | Not applicable — it runs once | Optional end date, which must be later than the start date |
| Timezone | Required | Required |
That refusal is a feature: it is what stops a one-off from silently becoming a series, or a series from having an invisible extra run.
The repeating pattern is a standard five-field cron expression, which covers the ordinary cases — hourly, daily, weekdays, weekends, a chosen weekday, a chosen day of the month — and allows a custom expression for anything else. Two shorthands people reach for are not accepted: alias forms such as an at-daily keyword, and six-field expressions that include seconds. Both are rejected on save rather than reinterpreted, so you find out immediately rather than at the first missed occurrence.
Decide the timezone: it belongs to the audience
The timezone is part of the schedule, chosen from the standard IANA list. Occurrences are computed in that timezone — not in UTC, and not in the timezone of whichever machine happened to create the schedule. Pick the timezone the audience lives in, and the pattern stays meaningful when the person who built it is travelling.
Then plan for the two days a year when a local wall-clock time is not a simple thing.
- Spring, the missing hour. A requested wall-clock time that does not exist that day advances to the next valid local instant. The occurrence happens; it does not vanish, and it does not silently move to the following day.
- Autumn, the repeated hour. An ambiguous wall-clock time runs once, not twice. A daily broadcast does not double up.
If a series absolutely must not land near either boundary, schedule it away from the small hours in its own timezone. That is a planning decision, not a setting.
Where the series stops
The end date on a recurring schedule is exclusive. An occurrence landing exactly on the end date does not run. This is the single most common “my series ended a run early” surprise, and the fix is to set the end date after the last run you want rather than on it. The end date also has to be strictly later than the start date, so a same-instant window is refused rather than saved as a series that can never fire.
If you only want to stop the series for now, disable the schedule instead. A disabled schedule keeps its definition, its sources and its timing, and can be re-enabled later.
Decide the playlist behaviour
Four controls, and they mean narrower things than their names suggest.
| Your intent | Control | What it actually does |
|---|---|---|
| A session with a deliberate running order | Leave the order as authored | Plays the list in the order you built it |
| Vary a library where order does not matter | Shuffle | Plays the same selection in an order the scheduler derives from the schedule and the videos themselves |
| Fill a longer slot with the same material | Repeat count | Adds extra passes over the whole playlist |
| Run a continuous channel from a finite library | Loop | Makes those passes endless |
Three traps live in that table.
Shuffle is stable, not random. It is an ordering the scheduler works out from the schedule and the videos, not a fresh draw. The same schedule with the same videos produces the same order at every occurrence, and for some selections that order coincides with the one you authored. If a series needs to feel different week to week, change the selection — shuffle will not do it for you.
Repeat counts passes, not plays. Two videos with a repeat count of one run A, B, A, B — not A, A, B, B. There is no way to repeat one item inside an otherwise ordered playlist; shuffle, repeat and loop are all per-schedule choices.
Loop supersedes repeat. Looping makes the passes endless, so a finite repeat count adds nothing on top of it. Set one or the other.
Playlist length and repeat count are both bounded. A very long list or a very high count is rejected when you save rather than truncated silently, so if a save is refused on a large series, split it rather than assuming it was accepted in part.
The five shapes of a silent no-show
Most scheduling problems are caught at save time and name the thing that failed. These are the ones worth checking deliberately before the first occurrence.
| Shape | Check first | Safe next action |
|---|---|---|
| A source was refused when saving | Whether that video is published, in this account, and has an entitled HLS or MP4 rendition | Publish or replace the item; the message names the video |
| The stream will not take a schedule at all | Whether the stream is on the current live system | Create the stream on the current system and schedule against that |
| The series ran one occurrence fewer than expected | Whether the end date is the day of the last wanted run | Move the end date past it — the end date is exclusive |
| An occurrence landed at an unexpected local hour | Whether the date is a daylight-saving boundary in the schedule’s timezone | Confirm the gap and overlap behaviour above; move the pattern away from the boundary hour if it matters |
| The schedule exists and nothing plays | Whether the playlist is empty | A schedule with no videos saves, but it has nothing to broadcast — add sources and save again |
That last row is the one that catches experienced operators: an empty playlist is a valid saved schedule. It just cannot run.
The replay is a separate decision
Scheduling a broadcast does not preserve it. Live stream recording is opt-in per stream and depends on your plan; nothing is recorded automatically, and a broadcast that ran without recording enabled cannot be recovered afterwards. If the plan is “run it live on Tuesday, then keep it as a replay”, the recording decision has to be made — with its destination project — before Tuesday, not after.
Frequently asked questions
Can I schedule a video hosted somewhere else?
No. Schedules play videos hosted in your own DynTube library, published and with a rendition your plan entitles. External video URLs are not a supported source.
Does shuffle give a different running order every broadcast?
No. It is a stable ordering derived from the schedule and the videos, so the same schedule and the same selection give the same order at every occurrence — and for some selections that order matches the one you authored.
Why did my recurring series stop a run early?
The end date is exclusive: an occurrence landing exactly on it does not run. Move the end date past the last run you want.
What happens at a daylight-saving change?
Occurrences are computed in the schedule’s own timezone. In the spring gap, a time that does not exist advances to the next valid local instant. In the autumn overlap, an ambiguous time runs once rather than twice.
Can I pause a series without losing it?
Yes. A schedule can be disabled and re-enabled later; its definition, sources and timing are kept while it is disabled.
Is a scheduled broadcast recorded?
Only if recording is enabled on that stream in advance and included in your plan, with a destination project chosen. Streams are not recorded automatically.
Where the procedure lives
This article is a planning guide. The controls themselves, the exact validation messages and the step order are on the live stream scheduling page; the wider capability, including how a live stream is created in the first place, is on the live streaming page; which plans include live streaming and recording is on the live streaming pricing page.
Verification boundary
No latency, capacity, uptime or availability figure is stated here, and no numeric playlist or repeat limit is published, because those bounds are contract configuration. Your own schedule’s save-time validation remains the authority for what a specific account, plan and stream will accept.
Sources
References, with the date each one was last checked.
- DynTube live stream scheduling
DynTubeChecked