Only forward: replacing dizqueTV with Tunarr

Some services arrive with a grand launch. Others quietly become important because they sit in the path of something the household uses every day.

Our virtual television stack was the second kind. For years, dizqueTV did its job from the Windows machine that also hosts Plex. It turned library media into familiar channel numbers and gave Plex something that looked enough like a tuner to make the whole arrangement feel ordinary. That was the charm, and eventually the problem. A useful little service had become attached to a host that already had enough responsibilities.

The replacement was Tunarr, running as a dedicated Docker service. Making a newer application answer on the same port would have been the easy part. We also wanted a cleaner ownership boundary, an internal-only route, and a tested recovery chain. The old service could not remain scattered across Windows, Nginx, the firewall, DNS, backups, and documentation.

Where the boundary moved

Moving from a Windows service to a container sounds like a packaging exercise. In practice, the most important change was deciding what belonged where.

Tunarr now owns the virtual-channel application state. Docker owns the runtime. The reverse proxy owns the friendly internal route. Authentik protects the management interface. Plex and compatible players still need machine-facing tuner, guide, image, and stream endpoints, so those paths cannot be shoved through a browser login flow. Instead, they are narrowly exposed only inside the trusted LAN and VPN boundary, with write methods denied where they do not belong.

That split matters. “Internal” should not mean “everything on the network can administer it.” The management surface is authenticated; the protocol paths that must behave like a tuner remain constrained to the networks and methods that actually need them.

Keep the channel identity, change the machinery

The human-facing promise was simple: the seven familiar channel numbers should survive the move. Tunarr was built with the same lineup, channel 200 and channels 209 through 214, while the old service was still available for comparison.

That side-by-side period exposed the difference between configuration and experience. A channel can exist in an API, appear in a lineup, and have guide data while still failing to produce useful video because its current program has no playable source. Real stream probes matter. So does checking Plex, not just the application that feeds it.

Three channels produced real transport-stream data during the final pre-retirement check. Four still needed content refinement, and Plex integration was still being improved. We chose not to let those tuning tasks turn the old Windows service into permanent life support. The operating decision was explicit: only forward. Tunarr became the production platform, and further work would improve Tunarr rather than preserve dizqueTV as a shadow system.

A backup is not a recovery plan

The backup design was intentionally layered. Tunarr first creates its own application-consistent archive, including the database and settings it understands. A validation job then rejects archives that are missing, stale, corrupt, or structurally incomplete. Only a valid archive is staged for Backrest and Restic.

That still was not enough. We ran the backup, restored it into an isolated target, verified the checksum, and opened the restored archive to confirm that the native database and settings payload were actually present.

This sounds fussy until the day a green “backup completed” badge turns out to describe bytes that cannot rebuild the application. The restore test is the point where a backup changes from an optimistic claim into useful evidence.

Decommission means more than clicking Stop

Once the forward-only decision was made, dizqueTV was removed as an operational option. The Windows service was stopped, disabled, and deleted. Its program and data tree was removed. The old host no longer listened on its service port. The reverse-proxy site was deleted and the proxy configuration revalidated. The exact firewall policy was removed. The active backup plan for the retired service was removed as well; historical repository data can age out under normal retention instead of pretending to be a supported rollback path.

Documentation was updated in the same pass. That matters because a stale runbook can resurrect a dead architecture months later. If the wiki says “start the old service,” a future operator may reasonably assume that the old service is meant to exist. Retirement has to be reflected in runtime, control planes, recovery tooling, and narrative records together.

What we would repeat

• Preserve channel numbers and client expectations instead of copying an old directory layout.
• Separate human management from machine protocols. Authentication and network restrictions solve different problems.
• Probe real output. A healthy API and a populated lineup do not prove that a channel plays.
• Restore before declaring backup success. Validation and isolated recovery belong in the deployment.
• Retire every control-plane reference, including routes, firewall rules, backup jobs, and documentation.
• State the lifecycle decision plainly. “Only forward” kept a temporary compatibility service from becoming a permanent second platform.

The quieter ending

There was no dramatic final switch. One service disappeared from a Windows host. Another kept running on Docker. The surrounding records were updated to match. Most of the work ended quietly.

Tunarr still has room to improve, especially around channel content and the last mile into Plex. Those are ordinary improvements to the chosen platform, not reasons to keep the retired one alive.