ChannelWatch: The Complete Monitoring Dashboard for Channels DVR

@Matthew_Crommert thanks, the screenshots help. I’m treating the watch-history / notification behavior as a separate bug. What stands out is that Active Streams can see the session, but Recent Activity and notifications are not following it. I’ll keep digging into that path.

@bnhf good catch on the Disk Space unit. You were right: that value should have been TB, not GB. That is fixed in v0.9.2, so the dashboard now formats large disk-space values correctly instead of forcing the GB label.

I’m also adding an in-app Report a Problem option for v0.9.3 so users can send sanitized diagnostics directly from ChannelWatch instead of manually putting together a zip.

Cheers,
CoderLuii
CoderLuii

Quick update for everyone since my last note:

I have the v0.9.7 fix implemented and in release checks now.

Changes included:

  • Live TV watch history/session state is now recorded before notification provider delivery.
  • If Pushover, Apprise, or routed delivery fails/rate-limits, the watch activity should still appear in ChannelWatch.
  • Live TV and DVR playback alerts now use a single outer provider delivery attempt so they do not keep retrying aggressively during provider rate limits.
  • Recording and disk alerts still keep retry/circuit-breaker behavior, since those are lower-frequency and benefit from retries.
  • Added regression coverage for failed provider delivery, repeated live-watch telemetry cooldown, channel/device changes, and route-specific retry behavior.
  • The GB/TB disk display fix is already included from the earlier update.

Moving forward, the easiest way to send diagnostics is the in-app Report a Problem option from Diagnostics. It creates a sanitized report/debug bundle path so manual zip uploads should not be needed.

v0.9.7 is not published yet, but this is the release I’m preparing for this fix.

Cheers,
CoderLuii
CoderLuii

@Matthew_Crommert quick update: I added the local notification receiver fix for v0.9.8.

The SSRF block was doing its job by refusing private/local destinations by default, but that was too rough for users intentionally sending notifications to a LAN receiver like Mattermost. The new behavior keeps the safe default, then lets you approve the exact local destination from Settings > Notifications.

So for a local Mattermost custom Apprise destination, ChannelWatch will still block it at first, but the UI will now offer a trusted-local approval for that exact scheme, host, and port. Metadata, link-local, loopback, reserved, malformed, unresolved, and image URLs still stay blocked.

Cheers,
CoderLuii
CoderLuii

Thanks again for the work - everything is working on my side now

Quick update: ChannelWatch v0.9.9 is released.

The main change in this release is the new Update Center in Settings. After installing v0.9.9 normally once, compatible app-only updates can be checked, verified, backed up, applied, restarted, and rolled back from the web UI.

If a future release needs a new container image because the runtime changed, ChannelWatch will say container image update required instead of trying to force an unsafe in-app update.

If you are updating from an older image, v0.9.9 also includes the recent live-watch history/session fix and the trusted local notification destination fix from the last two updates.

Docs are updated here:

ChannelWatch Official Docs Site

Images:

Docker Hub:
coderluii/channelwatch:0.9.9
coderluii/channelwatch:latest

GHCR:
ghcr.io/coderluii/channelwatch:0.9.9
ghcr.io/coderluii/channelwatch:latest

v0.9.9 gets the update path in place so compatible future updates can be handled from inside the app.

Cheers,
CoderLuii
CoderLuii

Quick update: ChannelWatch v0.9.11 is released.

This update fixes two noisy problems reported by the community.

Quiet Channels DVR event streams were being disconnected by a five-second HTTP read timeout. That caused ChannelWatch to enter the repeated 1, 2, 4, 8, 16, and 32-second reconnect sequence even when the DVR was healthy and simply had no event to send. Idle event streams now stay open, while real disconnects still use the existing health checks, reconnect backoff, and Retry-After handling.

The repeated timezone message had a separate cause. Normal dashboard requests were rebuilding the core settings object and reapplying the TZ override. Dashboard refreshes now use the existing settings snapshot, so the timezone message should appear during startup or a real configuration reload, not during routine polling.

v0.9.11 also repairs the image entrypoint used during Update Center restarts. This release therefore requires a normal container image update, but it does not require a settings or data migration. Settings > Updates will correctly identify it as container image update required.

On Unraid, use the normal container update action.

With Docker Compose:


docker compose pull

docker compose up -d

Docs:

ChannelWatch Official Docs Site

Images:

Docker Hub:

coderluii/channelwatch:0.9.11

coderluii/channelwatch:latest

GHCR:

ghcr.io/coderluii/channelwatch:0.9.11

ghcr.io/coderluii/channelwatch:latest

If you were seeing the repeated reconnect or timezone messages, please let me know how v0.9.11 behaves on your setup.

Cheers,

CoderLuii

CoderLuii

Is this your program back in OliveTin Project Oneclick?

ChannelWatch Stack in Portainer

Yes.

Thank you very much for confirming!!

1 Like

Thought I would install this and check it out. Seems to go ok but upon opening, I see this:

Any idea what this means? I just installed via project one-click, and ran watchtower just to be sure I have the latest version.

@Free Thanks for trying it. That screen is a little confusing because Connected and Fatal are reporting 2 different parts of ChannelWatch.

The connection test reached your DVR successfully. The Core Engine, which does the actual monitoring, stopped before it published its first status update.

I can’t tell the exact cause from the screenshot alone. It may have hit an error while starting, failed to read or write something under /config, or reached the main DVR API but failed on another request needed for monitoring. The debug bundle should show which one it is.

Click Diagnose, then open Diagnostics → Report a Problem. Add a short description of what happened and click Create fresh debug bundle before submitting it.

You’ll see the public report preview before anything is sent. The debug bundle and your screenshot are sent privately to me for troubleshooting. They won’t be posted in the public issue.

If direct submission doesn’t work, use the support code or offline package option shown in the same window.

Cheers,
CoderLuii
CoderLuii

1 Like

Quick update: ChannelWatch v0.9.12 is now available.

This release updates the app’s libraries and container components, along with security, compatibility, and general reliability improvements.

To update:

  1. Open ChannelWatch and go to Settings → Updates.
  2. Click Check for updates.
  3. ChannelWatch will let you know that v0.9.12 requires a container image update.

Since this release changes the container itself, it cannot be installed directly through the in-app updater. Update ChannelWatch using the same method you originally used:

• Unraid: Open the Docker tab, click Check for Updates, and apply the ChannelWatch update.

• Docker Compose: Run docker compose pull, followed by docker compose up -d.

• Docker CLI: Pull coderluii/channelwatch:0.9.12 or coderluii/channelwatch:latest, then recreate the container using the same settings and /config volume.

• Project One-Click: Use its normal update or redeploy option so it pulls the newest ChannelWatch image.

Your settings and history will remain intact as long as you keep the existing /config volume. No settings or data migration is required for this release.

For future app-only releases, you’ll be able to install the update directly from Settings → Updates. Updates that change the container, system libraries, or runtime will continue to ask you to update the container through your normal installation method.

Release notes:

Full update guide:

Cheers,
CoderLuii
CoderLuii

Tried to submit a bug report and having a devil of a time. I fill out the report and it all looks good but then says it just did a dry run and there's no button to do a full submit, just a one that says "done."

Tried the manual option several times but it says it can't copy support code. When I go to the upload portal, it wants a support code.

I tried deleting and reinstalling the app, but same problem with the app and with reporting.

2 Likes

@Free Thanks for letting me know, and sorry you ran into this. I found that the problem was on ChannelWatch’s side, not with your installation.

The app was mistakenly running the reporting system in preview-only mode, which is why it said “dry run” and never provided a full submit option. The manual fallback also depended too heavily on browser clipboard access, which commonly fails when ChannelWatch is opened through a local network address.

I’ve released ChannelWatch v0.9.13 to fix both problems.

Because this update changes the container, you’ll need to pull the new image rather than use the app-only updater.

If you installed it through Project One-Click or Portainer:

  1. Open the ChannelWatch stack or container.
  2. Pull/redeploy the latest coderluii/channelwatch:latest image.
  3. Make sure the existing /config folder remains mapped so your settings are preserved.
  4. After it restarts, open ChannelWatch and confirm the version shows v0.9.13.

If your current ChannelWatch installation can access the Update Center, it should also tell you that a new container image is required and guide you through the update.

In v0.9.13, reports are submitted normally from official container installations. The support code is also displayed in a selectable field and can be downloaded as a text file, so browser clipboard restrictions should no longer leave you stuck.

Once you’re on v0.9.13, please try submitting the report again. If the private attachments cannot be delivered, ChannelWatch will keep the same report and give you a retry option without creating a duplicate public issue.

Cheers,
CoderLuii
CoderLuii

Now when I click "Review Report," nothing happens. The button animation responds when cursor hovers over it, but it does not respond to a click and it never proceeds to the next page,

@Free Huh, that’s odd. The Review Report button does its work inside the browser, so no internet connection shouldn’t stop it there.

Can you send me a shot of the whole report window after you click it? I want to see if one of the fields is quietly blocking it. If you added a screenshot or debug bundle, try it once without those too.

No need to reinstall anything again.

Cheers,
CoderLuii
CoderLuii

Tried to submit without the debug bundle or screenshot. The button still was dead.


1 Like

@Free Yep, that confirms it. The screenshot and debug bundle aren’t causing the problem. The Review report button is failing before ChannelWatch even gets to the upload step.

I tracked down what’s happening and have the correction in place. I’m finishing the release checks now, and I’ll be putting out an update shortly. You’ll need to pull the new container image once it’s available.

No need to keep fighting with the form for now. I’ll post here as soon as the update is ready.

Cheers,
CoderLuii
CoderLuii

@Free I’ve released v0.9.14 with the fix. Open Settings → Update Center, check for updates, and install v0.9.14. You can apply this update directly inside ChannelWatch—there’s no need to pull or reinstall the container.

Once ChannelWatch restarts, please try Review report again. If it still doesn’t continue, send me a screenshot of the full screen with the version number visible and I’ll keep digging.

Cheers,
CoderLuii
CoderLuii

Just to update you, the review report button still doesn't do anything for me in the new version.

I appreciate your efforts and this seems like a potentially worthy project, but I'd just like see what it's like when it works properly and instead we've spent a lot of time troubleshooting how to even report the problem without getting to whether it can actually be fixed, so I'll probably stand down for now.

Thanks again.