The web interface
Ce contenu n’est pas encore disponible dans votre langue.
Signing in
Section titled “Signing in”The interface listens on port 8080 by default. Credentials come from the environment variables CASTMUX_WEB_USERNAME and CASTMUX_WEB_PASSWORD set when the container is started; there is no separate user store and no first-run account wizard.
A successful sign-in sets a session cookie that lasts seven days. Seven days is chosen so that an operator who checks the headend weekly is not re-authenticating at every visit, while a laptop left in a cupboard eventually stops being a way in.
One account, today
Section titled “One account, today”There is a single administrator account. Everyone who signs in has full control: they can edit channels, change engine defaults and reboot the appliance.
This is not good enough for a site where reception staff and the installer both need access, and it is worth saying plainly rather than dressing up. Reception needs to see whether a channel is on air and perhaps restart it; they do not need the ability to change the egress interface. A shared password means either the installer’s credentials circulate among staff, or staff have no access at all and every trivial question becomes a call-out.
Multiple users with distinct roles are on the roadmap roadmap. Until then, the realistic mitigation is network-level: restrict which addresses can reach port 8080.
Layout
Section titled “Layout”The top navigation carries the four working areas and two controls:
| Item | What it is |
|---|---|
| UDP channels | The main page. One card per multicast channel. |
| HDMI channel | Configuration for the local HDMI output, if the appliance has one. |
| DVB-C | Multiplex configuration and modulator status. |
| Settings | Appliance-wide defaults and site identification. |
| Theme toggle | Light or dark. Stored in the browser, not on the appliance. |
| Sign out | Clears the session cookie. |
The footer
Section titled “The footer”The footer is present on every page and shows the appliance’s own condition: version, CPU load, memory use, CPU temperature and per-interface network bitrate. It refreshes every fifteen seconds.
Two of these are more useful than they first appear. CPU temperature matters because the reference hardware is fanless and lives in a cupboard, and a blocked vent shows up here weeks before it shows up as instability. Per-interface bitrate is the quickest way to confirm that traffic is leaving the interface you think it is: if the television-facing NIC shows nothing while the management NIC shows several megabits, the multicast route is pointing at the wrong place — see Installation → multicast routing.
The channels page
Section titled “The channels page”One card per channel. The card is designed so that the question “is this channel on air?” is answerable without opening anything.
The active switch
Section titled “The active switch”Enables or disables the channel. A disabled channel is not started under any circumstances, regardless of viewers or the always-on setting. This is the switch to use when taking a channel out of service; deleting it loses the configuration.
Badges
Section titled “Badges”always-on / on-demand
Whether the channel runs continuously or only while somebody is watching. An on-demand channel showing no activity and no viewers is behaving correctly, not failing — a distinction worth remembering before raising a fault.
viewer count
How many clients have joined this channel’s multicast group, derived from observed IGMP membership rather than guessed. Hover to see the individual client addresses, which is how you confirm that the television in room 214 is the one actually watching.
engine
Which engine this channel is using. Worth checking before reading the metric tiles, because the two engines do not populate the same tiles.
resolution profile
The requested quality rung and, in brackets, what the origin actually had. See below.
The amber resolution badge
Section titled “The amber resolution badge”A resolution profile asks for a rung of the source’s quality ladder — 4K, Full HD, HD, SD or mobile. Origins publish whatever ladders they like, so the requested rung frequently does not exist. Castmux selects the closest available height rather than refusing to start, because a channel streaming 480p when you asked for 576p is better than a channel that will not start because nobody serves exactly 576p.
When the match is inexact the badge shows both values — 4K (1080p) means 4K was requested and 1080p is what the origin offered — and it is coloured amber.
Resolution profiles covers the selection rules, including why a ladder with separately delivered audio is refused outright.
Metric tiles
Section titled “Metric tiles”| Tile | What it is | Source |
|---|---|---|
| Bitrate | The rate the engine reports for the stream it is handling. | Reported by the engine |
| Speed | Whether the channel is keeping up with real time. Anything meaningfully below 1× is falling behind. | Reported by the engine |
| Uptime | How long this channel has been running since it last started. A short uptime on a channel nobody has touched is the signature of a restart loop. | Castmux |
| UDP bitrate | What is genuinely leaving the network interface for this group. | Measured off the wire |
| Source ping | Round-trip time to the origin. A useful early warning: source ping degrading before a channel becomes unstable points at the network, not at Castmux. | Castmux |
The distinction in the last column is the important one. Engine-reported figures describe what a process believes it is doing; UDP bitrate describes what happened. When they disagree, UDP bitrate is right. It is also the only tile that is populated identically on both engines — the pass-through engine never decodes video, so it has no frame rate or speed to report, and those tiles will be empty on a perfectly healthy pass-through channel.
Card actions
Section titled “Card actions”Four buttons: Preview, Logs, Edit and Delete. Delete asks for confirmation and removes the channel from the configuration; there is no undo beyond restoring a backup of the config directory.
Adding and editing a channel
Section titled “Adding and editing a channel”The same dialog serves both. Fields:
Name
Used in the interface and in logs, and on the pass-through engine it becomes the service name carried in the transport stream, so it is what a television may display.
Source type
HLS, SRT or RTMP.
Source URL
Where the channel is pulled from. For HLS this is normally the master playlist.
Destination address
The multicast group. Use the administratively scoped range, 239.0.0.0/8.
Destination port
The UDP port. Each channel needs its own group-and-port combination.
Engine
Pass-through or remux, overriding the appliance default for this channel.
Resolution profile
Which rung of the HLS ladder to select, or empty to accept whatever the origin lists first. Empty is the default and is what every pre-existing channel has.
Force always-on
Run the channel continuously instead of only while it has viewers.
Changes take effect on the channel’s next start, so editing a running channel restarts it.
Preview
Section titled “Preview”Preview plays the channel in the browser. It does so by re-reading the channel’s own multicast output rather than by opening a second connection to the origin, which means what you see is what the televisions are receiving, including any fault introduced between the engine and the wire. A preview that is broken in the same way as a television is genuinely informative; a preview that pulled from the source separately would not be.
Each channel keeps its own circular buffer of log lines — 1000 entries or 24 hours, whichever is reached first. The Logs button on the card opens it.
Per-channel rather than one combined stream, because the question being asked is almost always about one channel, and on a twenty-channel appliance a combined log buries the six relevant lines under several thousand irrelevant ones. The buffer is in memory and does not survive a restart, so capture anything you need before restarting the container.
The DVB-C page
Section titled “The DVB-C page”Where IP channels are assembled into a multiplex on a real RF carrier: modulator status, multiplex composition and carrier parameters. Present whether or not a modulator is fitted. Full detail is in DVB-C multiplexing.
The HDMI page
Section titled “The HDMI page”Configuration for the appliance’s local HDMI output — a single channel rendered to a directly attached display, typically for a foyer or waiting room screen. See HDMI output.
Settings
Section titled “Settings”Appliance-wide values, applied to every channel that does not override them:
Default engine
Which engine new channels use, and which existing channels use if they have no explicit choice.
Egress interface
The interface facing the televisions. Note that this does not by itself determine where multicast leaves — the kernel routing table does that. See Installation → multicast routing.
On-demand behaviour
Whether channels default to on-demand, and how the system behaves when viewer detection is unavailable. Covered in On-demand streaming.
Site identification
Names the installation, so an operator with three appliances open in three tabs can tell which is which.
A Settings change is applied to running channel managers immediately rather than being read once at start-up, so there is no need to restart the appliance after changing a default.
What is deliberately not here
Section titled “What is deliberately not here”Raw engine parameter strings are not exposed in the interface. They exist, and they can be set in /config/config.yaml — see the Configuration reference — but they are not editable from a browser.
The reason is blast radius. A malformed parameter string does not break one channel, it breaks the engine invocation for every channel using it, and it does so at the moment the next channel starts rather than at the moment the mistake was made. Putting that behind a text box on a settings page, where a plausible-looking edit takes an entire site off air at three in the afternoon, is not a good trade for the small number of installations that need it. Editing the file instead is a deliberate speed bump: it requires shell access, it produces something you can diff, and it is not something anyone does by accident.
System actions
Section titled “System actions”Restart all streams
Stops and restarts every channel without restarting the appliance. Channels come back staggered, roughly three seconds apart, so on a large installation this takes a minute or so to complete. The stagger is not cosmetic: starting everything at once saturates the source uplink and makes every channel fail together.
Reboot
Restarts the appliance. Worth reaching for less often than instinct suggests — a reboot cannot fix a multicast route pointing at the wrong interface, and it will not fix a source that has stopped serving. If a reboot appears to fix a problem that then returns, the reboot was not the fix.