ChannelWatch: The Complete Monitoring Dashboard for Channels DVR

Playground Hacks
#62

ChannelWatch v1.0.1 through v1.0.4

Several ChannelWatch updates have been released since v1.0.0, so here is one combined summary.

v1.0.1

This release reorganized Alerts around clearer notification policies:

  • Monitor Only
  • Important Only
  • Balanced
  • Everything
  • Custom

It also added more useful recording outcomes, including failed, skipped, missed, interrupted, cancelled, started, and completed recordings.

Other additions included:

  • DVR unreachable and recovery alerts
  • Exact Channels client filtering in Recent Activity and Watch History
  • Separate ChannelWatch Core, UI, and DVR uptime information
  • A dedicated Help & Feedback page
  • Update Center corrections for stale release information

Existing notification choices were preserved during the upgrade. New operational alerts were not silently enabled for existing installations.

v1.0.2

This release fixed the Update Center becoming stuck on:

Another update operation is already running

The problem was caused by an old scheduler lock being treated as if an update were still active. ChannelWatch now checks whether the operation is actually running and safely clears stale state when it is not.

v1.0.3

This release corrected several dashboard activity issues reported by @JefferMC:

  • The 24-Hour Timeline now consistently represents the number of detected activity events within each 20-minute interval.
  • Timeline values and tooltip values now use the same underlying data.
  • Tooltip times now follow the correct chart position.
  • Recent Activity pagination was corrected.
  • Active Streams now uses the same program-title fallback logic as Recent Activity instead of unnecessarily displaying Unknown.

v1.0.4

This release further refined the 24-Hour Timeline:

  • The tooltip now clearly explains that values are event counts for the displayed interval.
  • The misleading visible zero markers at the beginning of the graph were removed.
  • Hovering the chart now selects the correct time bucket more reliably.
  • Static frontend output is revalidated during the release process to prevent stale interface files from entering an update bundle.

Cheers,
CoderLuii
CoderLuii

#63

@JefferMC Thanks again for the detailed report. The timeline count, tooltip time, zero-marker, and Active Streams Unknown issues you identified were corrected across v1.0.3 and v1.0.4.

The timeline now clearly represents detected activity events within each 20-minute interval. Your screenshots were very helpful in reproducing and verifying these fixes.

Cheers,
CoderLuii
CoderLuii

#64

FYI, I upgraded to 1.0.0 by pulling the latest container image, so I expected I would have gotten a 1.0.0 container, etc. However, the upgrade page is telling a different story. I'll upgrade by pulling a new image, but, IMHO, I should have been able to go from 1.0.0 to 1.0.4/5/6 on the Upgrade page:

image
image1002×289 44.9 KB

Update, after the manual upgrade via image pull, the container version is the same

image
image1013×418 74.4 KB

#65

Can you submit this as an issue with the debug bundle?

#66

I can. Or I can wait until 1.0.7 comes out and see if it refuses to update again first.

#67

ChannelWatch v1.0.5 through v1.0.8

Several ChannelWatch updates have been released since v1.0.4, so here is one combined summary.

v1.0.5

This release improved how Settings behaves while ChannelWatch is restarting after an update.

ChannelWatch now waits for two consecutive healthy checks before refreshing the browser. If Settings are still temporarily unavailable, it shows a focused retry screen instead of displaying an empty configuration form.

This prevents:

  • Safari’s generic Load failed message during the normal restart window
  • Saved DVRs, timezone, and other settings from temporarily appearing missing
  • Save or Discard from being available before the real settings have loaded
  • An empty form from accidentally replacing preserved configuration

The Settings page can recover automatically once the restarted backend is stable.

v1.0.6

This release fixed the deeper frontend and backend mismatch that could happen after an in app update.

The new backend could activate correctly while the container continued serving an older frontend from the underlying image. That mismatch caused the Settings Load failed screen, apparently missing DVR configuration, a clipped Updates tab, and other inconsistent interface behavior.

Each activated app bundle now serves its own matching frontend. The release process also verifies the actual HTML and browser assets served from every compatible v1.0 container image.

Frontend and backend versions now remain aligned after:

  • An in app update
  • A UI or Core process restart
  • A rollback and reapply
  • A complete container restart

v1.0.7

This release improved what users see immediately after a successful update.

After activation, ChannelWatch now refreshes directly onto Dashboard Overview instead of reopening Settings → Updates.

The initial monitoring period is also shown as Monitoring starting while Core completes its first monitoring pass. This replaces the more alarming Monitoring stopped message during normal startup.

Rejected, failed, or timed out updates remain on their current recovery screen so the actual error is not hidden.

v1.0.8

This release made the post update transition more reliable and corrected container version reporting.

ChannelWatch now preserves the Dashboard handoff across the required browser refresh, even when the browser tries to restore the route that originally started the update.

While monitoring is starting or reconnecting, the Dashboard performs short, bounded background status checks. The status automatically changes to healthy after the first successful monitoring pass, without requiring the user to click Home or manually refresh the page.

The Update Center now reads the container version from immutable metadata stored inside the image. This prevents a stale CHANNELWATCH_IMAGE_VERSION value retained by Docker or another container manager from incorrectly reporting an older image or launcher protocol.

Updating

All four releases are signed Update Center releases.

If ChannelWatch is already running on a v1.0.0 or newer container image, no image pull or container recreation is required. Open Settings → Updates, click Check for updates, and apply the latest release.

Cheers,
CoderLuii
CoderLuii

#68

Since the newly fetched 1.0.6 won't upgrade to 1.0.8 without a new container pull, I did give you a bug report from the app. I also reported another issue with Recording Events. FYI.

Updates on 1.0.6