SRT Matrix Becomes OmniBridge: a Full Rebrand, a New Site, Two Real Crashes, and a Licensing Bug Caught Twice
The big one: SRT Matrix is now OmniBridge — a real, full external rebrand, not just a find-replace, followed by a customer-facing crash on Windows, a second crash on Linux that took two releases to actually fix, the same licensing bug caught on two different accounts, and a real rebuild of the marketing site's comparison and roadmap pages — including catching my own inaccurate pricing claim before it shipped.
SRT Matrix becomes OmniBridge, for real
Renamed the product for real: SRT Matrix is now OmniBridge, with
omnibridgevid.cc as its own new domain. Not a quick find-and-replace — a full
external rebrand across every system that had the old name baked into it: the GitLab project
itself (URL, clone links, CI references), the wiki,
jpps.us's own Software page,
the Windows installer and service name, the Debian package name, and the Rust crate/binary/UI/docs
inside the app itself. Real cross-system stakes to work through along the way: the store's
license rows already had "srt-matrix" stored as a product slug on real customer
licenses, so that needed an actual migration plan rather than a blind rename; the Debian package
rename followed the same Provides/Replaces/Conflicts transition already proven once before for
an earlier package rename, rather than improvising a new approach; and the Windows installer's
product code needed real thought, since renaming a product typically means deciding whether an
existing install upgrades in place or needs a fresh install.
Then built omnibridge-web, a brand-new marketing site, from scratch — Home,
Features, Pricing, Downloads, Release Notes, and a full Docs section (setup guides, a
ports-and-troubleshooting page, known issues, screenshots) — plus new rebrand assets: a new
logo/favicon and a newly-designed on-air "no signal" slate image for the app itself, iterated a
few times before landing on the final look. Everything below happened on top of that freshly
rebuilt foundation.
A Windows install that wouldn't start at all
Got a real screenshot from someone trying to run OmniBridge on a fresh Windows box:
"omnibridge.exe - System Error: The code execution cannot proceed because
Processing.NDI.Lib.x64.dll was not found." Launch-blocking, on any machine without the NDI
Runtime already installed. First instinct was to embed it the same way the bundled ffmpeg
transport already is — except that doesn't work here: ffmpeg is a subprocess spawned well
after main() starts, but the NDI DLL is a normal load-time import Windows
resolves before any of the app's own code runs. Nothing to embed-and-extract; it has to be a
real sibling file on disk before the process even starts.
Fixed by having the WiX installer place Processing.NDI.Lib.x64.dll next to
omnibridge.exe — verified for real with msitools
(msiinfo tables/export) against the actual published MSI, not just a
"should work" guess. Same release also dropped the portable .exe/.zip
download entirely — a bare exe can never carry a load-time DLL dependency with it, so MSI-only
is now the only Windows distribution.
Then a second, unrelated crash: "loads then closes," no dialog, nothing in the log. Root cause
was almost embarrassing once found — an unconditional panic! on any TCP bind
failure, and Windows release builds hide the console, so a panic has zero visible feedback.
Confirmed by the real panic text once I got it: os error 10048, port 8080 already
in use. First instinct was "must be another copy of OmniBridge already running, just open its
dashboard" — except the person hitting this reported back that winget, of all
things, had port 8080. Redesigned it to actually check: a live GET /api/version
against whatever's squatting on the port, confirming it's really OmniBridge (checking the
authors field) before assuming that — otherwise a real Windows message box now
explains what's actually happening instead of the app just vanishing. Also added a
util:CloseApplication to the installer itself, so an upgrade force-closes a
still-running old instance (including the pre-rename srt-matrix.exe) before
replacing its files, instead of leaving a stale process holding the port.
The same crash's Linux cousin, and a real rabbit hole through cargo's rustflags precedence
Got a second real report, this time from Linux: error while loading shared libraries:
libndi.so.6: cannot open shared object file. Exact same root cause as the Windows crash
— every build/dev machine so far happened to already have the NDI SDK installed, so nobody had
hit the gap a genuinely fresh install would. Bundled libndi.so.6 in the
.deb and built the binary with an RPATH pointing at where it gets installed,
verified locally by literally hiding the system's own NDI libraries and confirming the binary
still ran off the bundled copy alone.
Shipped it, then verified the real published .deb with
readelf — and the RPATH wasn't there. Bundled library, missing RPATH, silent
failure exactly like before. Turned into a real live debugging session on the build runner
itself: reproduced with an obviously-invalid rustc flag to prove the mechanism I'd used
(CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUSTFLAGS) was being silently ignored
entirely, then found why — the runner has a system-wide, unscoped RUSTFLAGS baked
into /etc/environment, and plain RUSTFLAGS sits at a higher
cargo precedence tier than the target-scoped env var I'd used. The mold-linker flag I'd set the
same way had been silently dead this whole time too — it only ever "worked" because it
happened to match what /etc/environment already had. Second release, this time
setting plain RUSTFLAGS in CI (confirmed by direct reproduction to actually
override the runner's environment), fixed it for real.
Showing what's actually in a license — and a bug it caught on two different accounts
Built out real visibility into what a license includes: the app's About page and header badge,
plus store.jpps.us's
/status and /account pages, all now show whether a license is Pro
(every add-on) or has specific ones, and badge a self-service trial clearly instead of leaving
that to be inferred from the expiry date.
Turning that on immediately surfaced a real bug: my own docs-testing license showed up as
"TRIAL" even though it's a real, manually-upgraded license with a 10-year expiry. Root cause:
is_trial is only ever set at trial registration and nothing ever clears it — an
admin manually upgrading a trial to Pro never touched that column. Fixed the one account by
hand, then a few messages later got told a second, completely different account had
the identical stale flag — same bug, independently confirmed. That was the signal to fix the
actual root cause instead of hand-patching every account that happened to surface it: the real
Stripe-driven "upgrade to Pro" purchase flow now clears is_trial the moment a real
payment lands, so a genuinely paying customer's license can't get stuck showing TRIAL forever.
Rebuilding the marketing site's Compare and Roadmap pages
The existing Compare page only covered one competitor. Rebuilt it against real research — Nimble Streamer, Magewell Control Hub, Haivision's SRT Gateway/Hub, the cloud-metered platforms (swXtch.io, TVU Grid, Vajracast), and the open-source tooling — checking every claim against the vendor's own site and pricing before writing it, the same discipline as the original SRT Mini Server comparison. Found real corrections along the way: Magewell's management software turned out to be hardware-locked to their own device line, not a standalone tool; TVU Grid's pricing is quote-only, not published per-stream the way I'd first assumed. Built as a real feature-by-feature checkmark matrix, which needed more width than the site's normal content column, so that one table gets a scoped full-bleed layout instead of widening the whole site.
Also added protocol icons to the Features page — the real official SRT and NDI marks (both genuinely licensed for this use, SRT under the SRT Alliance's general-implementer policy and NDI as an SDK licensee, with the required attribution text for each), and original, non-trademark glyphs for RTMP and RIST since neither has a safe official logo to use (Adobe never published one for RTMP at all, and RIST Forum's own logo looks membership-gated).
Built a real top-level Roadmap page too — the full detail already existed in the docs, three clicks deep with no link from primary nav. While drafting it, caught and fixed a genuine inaccuracy of my own before it could compound: I'd written that a hot-standby node runs "at zero additional license cost," which is wrong — install count is unlimited, but usage is summed across every install checked in under one key, so a standby mirroring the same live routing as the primary counts on both. Fixed it in all three places that repeated the same claim. The actual planned fix for that — an HA add-on that tracks the primary's routing instead of independently duplicating it, so it won't double-count — is now its own clearly-marked roadmap item, separate from the "here's the manual workaround available today" note.
Smaller cleanup
Removed the last real remnants of the pre-rename name: two old srt-matrix
.deb packages that had been sitting on the apt repo since before the switch to
OmniBridge, the completed rename plan/spec docs, and the old GitLab wiki's local git mirror
that wiki.jpps.us replaced. Fixed a docs error that had been backwards since it was written —
"destinations dial out as SRT listeners" doesn't actually parse; the gateway is always the SRT
caller toward destinations, verified against the relay code's own doc comment — and
added an explicit note that SRT Rendezvous mode isn't supported, for anyone specifically
checking firewall requirements before buying.