Home
XtreamUIPro

Setup guide

Universities & Campuses setup guide

Configure the platform as the television and video service of a university: campus channels, lecture archives by faculty, halls of residence on their own nodes, and student access driven by the student-information system.

These guides map an industry's concepts onto the objects the platform has today (bouquets, lines, packages, partner accounts, nodes, the API). They are conceptual mappings, not industry-specific features, and a partner account is a delegated account, not an isolated tenant.

Conceptual mapping

Nothing in the panel is called a faculty, a semester or a student. The table says which object plays which role; the chapters below set them up in that order.

In your industryOn the platformWhere in the panel
Faculty or department accountPartner account (reseller): a delegated dashboard with credits, permissions and its own linesUsers → add a reseller; Groups for its permissions
Faculty collection or campus line-upBouquet: a named set of channels, films or series that a package grantsBouquets, from Streams and Movies / Series
Campus channel or live eventLive channel: a stream with its sources, EPG and output formatsStreams → add a live stream (source URL or RTMP push)
Lecture archiveVOD catalogue: movies and series with seasons and episodes, categories and metadataMovies and Series, or the VOD ingest job
Student or staff accessLine: one access with its package, bouquets, expiry, connection limit and outputsLines → add, or activation codes, or the Reseller API
End of the semester or the enrolmentExpiry date of the line, renewed by a package, a credit or the APIThe line's expiry date and the package's duration
Campus or hall of residence nodeStreaming nodes: edge servers enrolled from the panel, one per site or buildingServers → add a node, installed over SSH
Student-information system integrationReseller API and webhooks: the operations of the panel from your own systemReseller API keys and webhooks in the reseller's dashboard

Prerequisites

What to have before installing.

  1. A server on the main campus (Ubuntu 22.04 or 24.04) reachable from the other campuses and the halls of residence, the installer, and an internal address or a domain behind your reverse proxy.
  2. The campus channel feeds and the lecture recordings (or the lecture-capture system's export), and the student-information system's ability to call an HTTP API.
  3. A decision on the structure: which faculties get a partner account, how lecture series are named, and how long a semester package lasts.

Infrastructure deployment

The main campus first, then the other sites.

  1. Run the installer on the main campus server; put the panel behind the university's reverse proxy and set the trusted proxies so logs and IP rules see real addresses.
  2. Set the playback base to the address students reach from the campus and the halls of residence.
  3. Enrol a node per campus and per hall of residence from Servers; the panel installs it over SSH and routes that site's viewers to it.
  4. Set the licence key on the server; an institution on an academic domain can request the free Professional key of the education programme by e-mail.

Content organisation

Faculty collections and the campus line-up.

  1. Create categories per faculty and subject, and one series per course with a season per term and one episode per lecture.
  2. Create one bouquet per faculty collection, one for the campus channels, and one for common material such as induction videos.
  3. Create packages for students and staff: the bouquets each needs, with the semester as the duration, so access ends with the term unless it is renewed.
  4. Create a short trial package for open days or visiting students.

Partner (reseller) configuration

Faculties as delegated accounts.

  1. Create a group with permissions for lines and the faculty's own catalogue, and no access to settings.
  2. Add each faculty or department as a partner account (reseller) with that group and its packages; sub-resellers can mirror departments within a faculty.
  3. A faculty sees and manages only its own lines; the central team keeps the whole view. It is a delegated account, not an isolated installation.

Student access configuration

One line per student, from the SIS.

  1. Create a Reseller API key for the student-information system and keep it in that system's secrets.
  2. At enrolment the SIS calls action=create_line with the student's package and a request id; the package's duration, the semester, is the access period.
  3. Set max connections to the number of devices a student may use at once (typically two: phone and laptop).
  4. For staff and for a pilot, add lines from Lines → add and hand out the credentials.

Lecture archives

Recordings on demand.

  1. Upload each recording as an episode's source or ingest it with the VOD ingest job; keep the course title and a short description.
  2. Attach the series to the faculty's bouquet, so only students whose package grants it see the course.
  3. Check playback with a test line of each package to confirm who sees what.

Campus channels and live events

Live channels for the campus.

  1. Add the campus channel feeds as live streams under Streams and an EPG source for the guide.
  2. Add a live stream per lecture hall or event, fed by the hall's encoder over RTMP, and enable catch-up so late viewers can rewind.
  3. Put each channel in the right bouquet; the nodes in the halls of residence take it once from the origin and serve students locally.

Expiry and renewal

The semester as the line's validity.

  1. A line expires at the end of its package's period; at re-enrolment the SIS calls action=renew_line and another period is added.
  2. When a student withdraws or graduates the SIS calls action=disable_line.
  3. Subscribe the SIS to the webhooks to reconcile expiring and expired lines with its records.

Integration with the student-information system

The SIS drives access; the player plays.

  1. The SIS creates, renews, enables and disables lines through the Reseller API with a key and a request id.
  2. There is no single sign-on for viewers and no native LMS or SIS integration: a student signs in to the player with the line's credentials, and a course page in the LMS can link to the web player.
  3. Use Admin API keys with the read-only flag, an IP allow-list and an expiry date for internal reporting tools.

Security considerations

Keep access to students and staff.

  1. Keep the platform on the campus network or behind the reverse proxy with TLS; set TRUSTED_PROXIES to the proxy.
  2. Two-factor sign-in for every panel account and a permission group per role, so a faculty cannot see another faculty's lines.
  3. Signed and expiring playback links, a connection limit per line, and binding to a country or an address where it helps.
  4. Encrypted database backups with an off-site copy, and the audit log for every change of lines and catalogue.

Troubleshooting

The usual first checks.

  1. A student sees no lectures: check the line's expiry, then the package and the bouquets it grants.
  2. A new student has no access: check that the SIS call succeeded in the Reseller API call log and that the request id is new.
  3. A hall of residence buffers in the evening: check its node's heartbeat and that viewers are routed to it.
  4. The audit log shows the proxy's address: set TRUSTED_PROXIES to the proxy and restart the panel.
Start free Help centre Contact