ChannelWatch: The Complete Monitoring Dashboard for Channels DVR

[CoderLuii]

@bnhf Thanks for updating Project One Click. That will work well for v0.9.17.

I’m working on v0.9.18 as we speak. Hopefully it will be ready within a few hours if I have enough time to finish testing everything properly.

Fresh v0.9.18 installs will not need CHANNELWATCH_SECRET_STORAGE_KEY. ChannelWatch will create and manage its own key inside /config. Existing v0.9.17 installs can keep the generated key for the first v0.9.18 startup so their saved credentials migrate safely.

Thanks again!

Cheers,
CoderLuii

[JefferMC]

FYI, I didn't use project one-click to install this. I just copied the compose YAML and set up the stack in Portainer. I don't know what difference that makes, but thought you should have that information.

It appears that this means I am responsible to creating a secret key. Just use OpenSSL to create a random key and set it in the environment var?

I looked at the container log first. I now see the message on the site. It's nice and clear.

After setting up the secret key in the YAML and environment vars and deploying that, It now looks more like I expect it to. The "degraded" warning box did come up for a minute or so, but then went away. The alert tests I have done instantly showed up as expected.

[AeroR1]

yea, im about to tap out of this project. its too complicated just to see who is streaming what. it never monitors and now you have to add a secret key? it gets more tedious as updates roll in and hopefully this gets much easier to use.

[CoderLuii]

@JefferMC Thanks for clarifying! This was not specific to Project One-Click. In v0.9.17, ChannelWatch was not automatically generating its credential-protection key, so monitoring remained blocked until one was added manually.

I’m glad monitoring and the alert tests are now working. Starting with v0.9.18, ChannelWatch will handle the key completely by itself inside /config. Users will not have to generate it, view it, copy it, add it to Portainer or Compose, or think about it at all.

Thanks again!

Cheers,
CoderLuii

[CoderLuii]

@AeroR1 I understand the frustration. You’re right, this became way more complicated than it should have been just to monitor who is watching what.

The storage key was supposed to be handled automatically, but v0.9.17 required users to create and add it themselves. Without the key, the interface could still load while monitoring stayed blocked, which made the problem even more confusing.

I’m fixing this in v0.9.18. ChannelWatch will create and manage the key automatically inside /config. You will not have to generate it, find it, copy it, add it anywhere, or even think about it.

I’m also improving the monitoring diagnostics so if something still does not connect, ChannelWatch will clearly explain what is wrong instead of just looking like it is not monitoring.

Cheers,
CoderLuii

[JefferMC]

I thought I should throw this out here: I am less interested in knowing about every instance of a recording being made or viewed, and more interested in knowing of a recording that was scheduled isn't actually happening, or is having some sort of errors, or that the application itself is having issues or not responding. I don't see a lot of controls around these sort of alerts, and I've been wondering if they're just implied/automatic (of course you want to know that) because I'm turning off almost all the notifications I have control of.

[JefferMC]

As long as I'm giving feedback:

1. I was a little surprised that System Uptime is that of the Channel Watch, not the Channels DVR systems. I suppose that given that you can monitor multiple DVRs that can have multiple uptimes this might make some sense, but I really don't think it's important enough for a tile.
2. The "24-Hour Timeline" is showing no activity, which is clearly in error. I've been getting notices (and disabling them as they annoy me), but the DVR is definitely recording and playing back stuff.

[CoderLuii]

ChannelWatch v0.9.18, v0.9.19, and v1.0.0

A few ChannelWatch releases landed close together, so here is one combined update.

v0.9.18

ChannelWatch now creates and manages its own credential encryption key inside persistent /config.

Normal installations no longer need CHANNELWATCH_SECRET_STORAGE_KEY. Saved DVR and notification credentials remain encrypted, but users do not need to generate, enter, copy, or preserve a separate deployment key.

This release also introduced the newer signed Update Center, automatic update policies, and improved support for LAN, .local, single label, and Tailscale DVR hostnames.

v0.9.19

This release fixes the empty Recent Activity and 24-Hour Timeline problem.

ChannelWatch was detecting events and preserving them in activity_history.json, but the dashboard could read an empty SQLite activity table instead. That made valid live TV, movie, episode, and recording activity appear missing.

SQLite is now the main activity store. Existing valid activity is migrated automatically, and Recent Activity, the timeline, per-DVR history, feeds, backups, clearing, retention, and DVR deletion now use the same storage rules.

No DVR credentials need to be entered again, and users should not edit the activity files manually.

v1.0.0

v1.0.0 is the first container-image milestone under the new release schedule.

This release aligns the application and container runtime, introduces launcher protocol 3, and fixes the Update Center status race that could temporarily replace version information with Unknown when two update checks overlapped.

Starting now:

• Versions ending in .0, such as v1.0.0 and v1.1.0, require the matching container image.
• Versions v1.0.1 through v1.0.9 will install through the signed in-app Update Center.
• After v1.0.9, the next milestone will be v1.1.0.

Updating to v1.0.0

Pull and recreate the container using:

coderluii/channelwatch:1.0.0

Preserve the existing /config volume or directory. That contains the ChannelWatch settings, credentials, encryption key, database, activity history, and backups.

GitHub release:

Release v1.0.0 · CoderLuii/ChannelWatch

Docker Hub:

https://hub.docker.com/r/coderluii/channelwatch/tags?name=1.0.0

The v1.0.0 image is available for both AMD64 and ARM64.

Cheers,
CoderLuii

[CoderLuii]

@JefferMC Thanks for the feedback. I agree that ChannelWatch needs a clearer separation between informational alerts and alerts that require attention.

Live TV and playback alerts should be easy to silence, while recording failures, disk warnings, an unreachable DVR, and ChannelWatch not responding should be easier to prioritize. The current controls are spread across Alerts, Notifications, and Routing, so I am adding clearer grouping and presets to the v1.0.1 list.

The empty timeline was a real storage bug. ChannelWatch detected the activity, but the dashboard sometimes read from an empty database instead. That was fixed in v0.9.19 and is included in v1.0.0.

You are also right about System Uptime. It currently means ChannelWatch uptime, not DVR uptime. I will make that clearer and see if I can redesign that area to display uptime for all configured DVRs as well.

Thanks again. This is useful feedback.

Cheers,
CoderLuii

[AeroR1]

now were talking! everything is working! thanks.

if I can give a feature request, it would be cool if in recent activity, you can filter by channels client. I have so many clients that I would like to see what specific ones did. thanks.

[CoderLuii]

@AeroR1 Glad to hear everything is working now!

That is a good request. Watch History already saves and displays the client name, so I am adding a dedicated client filter there and to Recent Activity. This will let you select a specific Channels client instead of searching manually.

I am also adding a new Help & Feedback option inside ChannelWatch. It will let users report a problem, request a feature or change, or ask a question. Submissions will be organized through GitHub so they are easier for me to track and follow up on.

I am working this into v1.0.1 now. Thanks for the suggestion!

Cheers,
CoderLuii

[JefferMC]

I've upgraded to 1.0.0. Further feedback:

1) The graph now shows some traffic, but:
(a) the numbers in the chart are all zero (in the example, the graph indicates Recordings should be 4, not zero, and VOD looks like 1, not zero), and
(b) I'm not sure what the height/numbers represent? stream-hours of recording/viewing? Simultaneous streams at that particular point in time?

2) this shows unknown,

while this shows a program:

(yes, I'm sure it's the same thing)

**UPDATE: ** I think I answered 1b:

It's the number of events occurring in the interval ending at the time shown. There were a lot of "Recording events" shortly after 5:00 AM when the schedule update arrived and 10 instances of new programs got scheduled. Note that the Recordings shows 2 (not 10, not zero). But also note that the time doesn't match the grid for the cursor; there's something wrong with the logic for calculating what time should be shown in the popup box based on the cursor position.

[CoderLuii]

@JefferMC Thanks for testing this and for including the screenshots. You found several real display issues.

The timeline is intended to show the number of activity events detected during each 20 minute interval. It is not measuring viewing duration or simultaneous streams. That needs to be explained more clearly in the interface.

The zero values, recording count mismatch, and tooltip time not matching the cursor are bugs. The Active Streams card showing Unknown while Recent Activity has the program information is also a bug. Those two views currently resolve the information differently, and they should agree.

I’m writing these corrections for v1.0.2. I’ll reproduce each issue, correct the timeline calculations and metadata handling.

Depending on your next test, I might ask for you to submit an issue via in-app reporting system in order to patch Active Streams / Recent Activity bug.

Thanks for documenting everything clearly.

Cheers,
CoderLuii

[CoderLuii]

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]

@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

[JefferMC]

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:

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

[CoderLuii]

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

[JefferMC]

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

[CoderLuii]

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

[JefferMC]

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.