Contents
Clips Are Automatic
Reviewing Clips
Uploads
Signage
Clips Are Automatic
Cutting and publishing clips is a pipeline that runs on its own as matches are detected during the event — there’s no button an operator clicks to “publish” a match. Your job here is reviewing what came out the other end, not approving each clip before it goes out.
Reviewing Clips
The Clips page lists clips across your events, with each clip’s status and a link through to the uploaded YouTube video. Use it after an event to spot-check that every match got a clip and uploaded correctly. A clip that comes out noticeably longer than expected still publishes normally; there isn’t a separate on-screen flag for that case, so a quick spot-check after the event is the way to catch it.
If a clip’s actual duration comes out more than the clipping-tolerance setting shorter than the match’s expected length, it’s held rather than published automatically: its status badge reads Needs Review, with the reason in red under the clip name: “Shorter than the scheduled match; check before approving”. (A clip held for any other reason reads “Held for review after an automatic check”.) Watch the clip before you decide. From there, a member with User or above (or a system admin) has two actions:
- Approve — queues the clip for upload exactly as a normal clip would be (branding and pre-roll are already applied, and the test-event upload setting still applies if it’s a test event). If the upload can’t be queued, the clip goes back to Needs Review and you’ll see: “The upload could not be queued, so the clip was returned to review. Please approve it again.” — clicking Approve again is the fix. In the rare case the automatic recovery also fails, you’ll instead see “Approve failed and automatic recovery also failed; contact an administrator.”
- Discard — deletes the clip’s file and marks the clip failed and the match missed. It confirms first with a dialog titled “Discard filename?”, the message “This deletes the file and marks the match missed.” and a Discard button. If storage is briefly unavailable, Discard shows an error and the clip stays in Needs Review; clicking Discard again completes it.
Both actions are recorded in the audit log. Readonly members see Approve and Discard dimmed with ”🔒 Needs User or above”. A held clip can’t be deleted or archived directly — it has to be approved or discarded first.
Requeue (on failed and finished clips, User or above) sends a clip through processing again. On any other clip it is refused with “Only a failed or finished clip can be requeued”. If the old stored file can’t be removed first, Requeue is refused with “Could not delete the stored file; try again or contact an administrator” and the clip is left as it was. If the clip can’t be queued, you’ll see “Could not queue the clip for processing; requeue it again” and the clip is marked failed — click Requeue again.
The reason under a clip’s name is one of a fixed set of plain-language messages, on the Clips page and in the control center’s clips table alike:
| Shown | Meaning |
|---|---|
| ”Shorter than the scheduled match; check before approving” | Held: the clip is shorter than the match should be. Watch it, then Approve or Discard |
| ”Held for review after an automatic check” | Held for any other reason. Watch it, then Approve or Discard |
| ”Clip processing failed” | The clip failed. Requeue it |
| ”A processing attempt failed” | An earlier attempt failed; the clip’s status badge shows where it stands now |
Storage paths and the underlying error are visible to system admins only. If you need the details, contact your system admin with the clip’s name.
Archiving and Deleting Clips
Both actions need Client Admin:
- Archive is on every row. It confirms first: “Archive filename?” / “Its stored files are deleted. The clip stays in the list, marked archived.” with an Archive button. It is refused with “Held for review — approve or discard it instead” on a held clip and “Already archived” on an archived one; if it fails you’ll see “Archive failed”.
- Delete is on clips that still have stored files. It confirms first: “Delete files for filename?” / “The clip and its stored files are removed.” with a Delete button. A held clip must be approved or discarded first.
If storage can’t remove a clip’s files, Archive and Delete show “Could not delete the stored file; try again or contact an administrator” and nothing changes; try again. “The stored file is busy; try again in a moment” means another action on the same file is still running.
Uploads
The Uploads page lists every clip’s YouTube upload with a status badge:
| Badge | Meaning |
|---|---|
| YT: Queued | Waiting to upload |
| YT: Uploading | Upload in progress |
| YT: Uploaded | Done |
| YT: Failed | The upload failed after retries — a Requeue button on failed rows tries again (User or above; Readonly sees it dimmed) |
| YT: Deferred | The platform’s current operation mode is holding uploads back — a system admin needs to change the mode, or explicitly force it through |
| YT: Quota wait | The shared daily YouTube upload quota is temporarily used up — this clears on its own once the daily quota resets, no action needed |
| YT: Paused | A system admin has paused all uploads platform-wide — this is not something tied to your event, and only a system admin can resume it |
The status filter dropdown lets you narrow the list to most of these (All statuses / Queued / Uploading / Uploaded / Failed / Deferred / Quota wait); note that a paused upload still shows its “YT: Paused” badge in the table even though there’s no separate filter option for it.
Requeue on any other upload is refused with “Only a failed upload can be requeued”.
When an upload has gone wrong, the reason shows in red under its title (and under the clip in the control center’s clips table). It is one of these fixed messages; a long one is cut short, so hover over it to read it all:
| Shown | What to do |
|---|---|
| ”No YouTube channel is set up for this event” | Ask a Client Admin to choose the event’s upload channel (see Event Configuration Reference), then Requeue |
| ”The YouTube channel needs to be reconnected” | Ask a Client Admin to re-link the channel (see YouTube and Slack Integrations), then Requeue |
| ”YouTube’s daily upload quota was reached” | The shared daily quota is used up. A YT: Quota wait upload resumes by itself once the quota resets; Requeue a YT: Failed one after that |
| ”Replaced by a replayed match” | Nothing: the match was replayed, and the replay’s clip takes this one’s place |
| ”The clip file could not be read for upload” | Requeue; if it fails again, contact your system admin with the clip’s name |
| ”YouTube rejected the upload” | Requeue; if it fails again, contact your system admin with the clip’s name |
| ”An earlier attempt failed; it will be retried” | Nothing: the upload is queued or running again |
| ”The upload failed” | Requeue; if it fails again, contact your system admin with the clip’s name |
A finished upload shows no reason, even if an earlier attempt failed. The underlying error from YouTube or storage is visible to system admins only.
See Troubleshooting if uploads stay stuck longer than you’d expect.
Signage
If your event has signs assigned, manage them from the Signage page, which every member can open. Available display types are the pit, queueing, audience and wait-times displays for the event’s program (FRC or FTC) — five named presets, Official Pit Display, Nexus — Pit, Nexus — Queueing, Nexus — Audience, and Nexus — Test Area Wait Times — plus Livestream (see below) and a free-form Custom URL. (Exactly which presets are usable depends on whether a URL has been configured for your program; an unconfigured preset shows as disabled in the dropdown, marked “(URL not configured)”.)
Each sign is tied to one stream key at a time. The first time a sign is assigned to a stream key, a confirmation dialog appears: “Take control of this sign? This sign’s current AbleSign playlist will be replaced with a single item this platform controls. AbleSign’s media library is untouched, but releasing control later will not restore the sign’s previous playlist — it will show this platform’s idle page instead.” — confirm with Take Control. Assigning (or reassigning) a sign to a stream key, and setting the AbleSign API key, need Client Admin. Once a sign is assigned, anyone with User or above can switch which display it’s showing, Refresh the sign list, Re-apply, and use Reload, Screenshot and Reboot on a sign. The page refuses some actions before sending them: “The sign is offline — try again once it reconnects” and “Paste an API key first”.
Only one event controls a stream key’s signs at a time. An event’s signage can be turned on from its setup day (the day before it starts) through its last day, and turned off on any day. Changing an event’s stream key releases its signage. When no event controls a sign, it shows a client-branded idle page.
Each sign shows a sync status: Idle, Applying…, Applied, Drifted, or Error. Drifted means the sign’s playlist genuinely no longer shows this platform’s item in AbleSign — the platform only flags this after 3 consecutive successful playlist checks all confirm the item is missing, so a single API error, timeout, or unexpected response doesn’t flag the sign; it’s just retried on the next poll. Signs an event is controlling are checked every 2 minutes by default; signs no event is controlling are checked less often, every 10 minutes by default, so drift on one of those can take longer to show. Whether a sign is online is refreshed at the faster pace for every sign. Error shows the raw error message underneath the badge; if it doesn’t make sense, pass it along to your system admin.
What happens once a sign is confirmed Drifted depends on your system admin’s Signage Drift Action setting (see System Settings Reference):
- Leave (mark Drifted) (the default) — the sign is marked Drifted and unmanaged until you click Re-apply (which only appears in this state) to hand control back to the platform.
- Reclaim (auto re-apply) — the platform re-applies its playlist item automatically once drift is confirmed; the sign stays managed and its status text notes the reclaim. If an automatic reclaim attempt fails, the status shows an error with the reason and the next poll retries it — no action needed from you unless it keeps failing.
Turning an event’s signage on or off entirely (as opposed to picking what it shows) is done from that event’s control center or the Events list — see Running a Live Event.
The Livestream Display
A sign set to Livestream plays the controlling event’s YouTube broadcast for today. Signs are always muted. When nothing is live today, the sign shows a client-branded waiting page reading “Waiting for Livestream”, and it switches to the broadcast by itself once the broadcast starts — nobody needs to touch the sign.