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 its own new domain. Not a quick find-and-replace — a full rebrand across every system that had the old name baked into it: the GitLab project, the wiki, jpps.us's own software page, the Windows installer, the Linux package name, and the name inside the app itself. Real things to work through along the way: existing customer licenses had the old product name saved on them, so that needed an actual migration plan rather than a blind rename; the Linux package rename followed the same proven approach from an earlier package rename; and the Windows installer needed real thought, since renaming a product usually means deciding whether an existing install upgrades in place or needs a fresh one.
Then built a brand-new marketing site from scratch — a home page, features, pricing, downloads, release notes, and a full documentation section (setup guides, a troubleshooting page, known issues, screenshots) — plus new branding: a new logo, and a newly designed on-air "no signal" image for the app itself, redone 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 machine: it wouldn't start at all, complaining about a missing video-networking file. This hit any machine that didn't already have that video software installed separately. My first idea was to bundle that file inside the app the same way another piece of software it relies on already is, but that doesn't work here — the file Windows is missing has to already be sitting next to the program before it even starts, there's no way to unpack it from the inside at that point.
Fixed it by having the Windows installer place that file next to the program itself, and double-checked the actual published installer to make sure it was really in there, not just assumed. The same release also dropped the standalone download that didn't use an installer at all, since that version could never carry the missing file with it anyway.
Then a second, unrelated crash: the app would open and immediately close, no error message, nothing in the log. Almost embarrassing once I found it — the app was crashing outright whenever it couldn't claim the network port it needed, and Windows hides any error message on a crash like that. Once I could actually see the real error, it turned out something else — Microsoft's own package manager, of all things — was already using that same port. Redesigned it to actually check what's using the port before assuming it's a second copy of OmniBridge already running: now a real message box explains what's actually happening instead of the app just vanishing. Also set up the installer so that updating OmniBridge force-closes any still-running old copy first, instead of leaving it stuck holding the port.
The same crash's Linux cousin, and a build-settings rabbit hole
Got a second real report, this time from Linux: the app couldn't find the same video networking library it needed. Exact same root cause as the Windows crash. Every one of my own build machines already had that software installed, so nobody had hit the gap a genuinely fresh install would. Bundled the missing library into the install package and pointed the app at it directly, verified locally by hiding my own system's copy and confirming the app still ran off the bundled one alone.
Shipped it, then checked the actual published install package by hand, and the setting that points the app at the bundled library wasn't actually in there. Bundled library, missing setting, same silent failure as before. Turned into a real debugging session on the build server itself: I found that the build server has one of its own global build settings that was silently overriding the one I was setting for this project specifically, because of how those two settings are prioritized. A second release, this time setting it the way that actually takes priority, 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 itself and the account pages on the store now clearly show whether a license is the full Pro bundle or has specific add-ons, and label a free trial clearly instead of making someone work it out from the expiry date.
Turning that on immediately surfaced a real bug: my own test license showed up as a trial even though it's a real, manually-upgraded license good for 10 years. The trial flag only ever got set, never cleared, so an admin manually upgrading someone from trial to a real license never touched it. Fixed that one account by hand, then a few messages later got told a second, completely different customer account had the exact same stale flag — the same bug, independently confirmed. That was the signal to fix the actual cause instead of patching every account that happened to hit it: the real purchase flow now clears that flag the moment a payment actually lands, so a paying customer's license can't get stuck showing as a 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 comparison. Found real corrections along the way: Magewell's management software turned out to be locked to their own hardware, 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 table, which needed more room than the rest of the page, so just that table gets to run wider than everything else instead of widening the whole page.
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.