@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
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
Can you submit this as an issue with the debug bundle?
I can. Or I can wait until 1.0.7 comes out and see if it refuses to update again first.
Several ChannelWatch updates have been released since v1.0.4, so here is one combined summary.
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:
Load failed message during the normal restart windowThe Settings page can recover automatically once the restarted backend is stable.
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:
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.
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.
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
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.
Four more releases have been published since my last summary. The current release is v1.1.2.
@JefferMC, thanks for sending both reports. I reproduced the recording issue where a completed recording could later also appear as interrupted, and the fix is now released in v1.1.2.
I also reproduced a case matching your update problem. An older installation could read a stale container version retained by the container manager and incorrectly decide that an image update was required. My earlier update instructions didn't account for that situation. I've included the current update steps below, since v1.1.0 now introduces a required container image update anyway.
This release focused on activity reliability, safer DVR removal, and Settings and Dashboard behavior.
This is a container image milestone. Moving from the 1.0 image line to 1.1 requires updating the container image.
The main changes are:
This release completed a Safari accessibility fix and cleaned up documentation and support forms.
If a restart timed out, Safari could let keyboard focus escape the recovery dialog. Focus now stays within its recovery controls, and closing the dialog restores focus appropriately.
The update guide also explains the difference between the application version and the container image version more clearly. For example, running application v1.1.2 on the v1.1.0 image is expected.
Other changes corrected release comparison links and issue-form labels, stopped ordinary security questions from automatically receiving critical priority, and removed unused interface code.
This release fixes the reported Completed followed by Interrupted recording problem.
Some DVR recording responses don't include the recording's job ID. ChannelWatch could record the completion, then fail to recognize that same job as completed during a later monitoring check. That could produce an incorrect Interrupted event for a recording that had finished successfully.
ChannelWatch now resolves the recording's exact file and job identity from DVR metadata. It doesn't guess based on the program title or recording time. If that metadata cannot be read or matched, the result remains unknown instead of being treated as evidence that the recording disappeared.
This addresses both reports of the same problem. The fix applies to future processing; it doesn't remove older entries already stored in Activity.
@JefferMC, once you've updated, please let me know if you see another completed recording subsequently marked as interrupted.
If you're still using a v1.0.x or older container image:
Update the container to the v1.1.0 image or a later v1.1.x image using your normal container update process. Preserve your existing configuration volume and storage key, if configured, when recreating it.
If you update to the v1.1.0 image, you can then install v1.1.2 through Settings → Updates → Check for updates.
If you're already using the v1.1.0 image or a later v1.1.x image:
Open Settings → Updates, click Check for updates, and install the latest release. v1.1.1 and v1.1.2 are signed Update Center releases and don't require a newer container image.
The version pattern going forward is:
Thanks again for the reports and follow-ups. They helped identify the recording problem and clarify where the update instructions needed more detail.
Cheers,
CoderLuii
FYI, I upgraded to 1.1.2 by container pull of latest. We'll see when you make another release how that goes. But the base container version did move from 0.7 (IIRC) to 1.1.0.
Too soon to tell on the cancelled recordings that finished.
Quick follow-up to my last update: ChannelWatch v1.1.3 is now released. The v1.1.2 fix for recordings showing “Completed” and then “Interrupted” is included.
This release fixes a separate false alert. If ChannelWatch missed a recording’s start event, it could later say the recording “did not start” even though it completed normally. It now checks the completed recording before sending that alert. Recordings that really did not start will still alert.
There’s also a Program image switch under Settings → Alerts → Recording Outcomes, with a per-DVR override. Turn it off to remove artwork from those notifications without changing artwork on the dashboard. I also updated the web interface’s Next.js and Sharp dependencies to patched versions.
If you have a working v1.1.0-or-newer container image, use Settings → Updates → Check for updates to install v1.1.3. You don’t need to replace that container image. If you’re still on a v1.0.x or older image, update the container first and preserve your existing configuration volume and storage key, if you use one.
Cheers,
CoderLuii
I have not seen a repeat of the cancelled, but already completed message, so that looks good. I had yet another upgrade issue. Logged it in app and provided post mortem of how I got the upgrade to succeed. I'm upgraded, I just thought you'd want the report.
@JefferMC Thanks for confirming the recording error hasn't come back and that the update reached 1.1.3.
I've released v1.2.0 with updated container dependencies and a fix for Retry showing a network error while the dashboard restarts. The original restart failure is still being investigated in #22.
This release needs the container image update. Use coderluii/channelwatch:1.2.0 or latest, keeping the same /config volume and any external storage key you already use. The Update Center can't install this one in-app.
The recording fixes and Program image setting from v1.1.3 are still included.
Cheers,
CoderLuii
There have been several releases since my last update covering v1.1.3. The current release is v1.6.0.
The biggest changes are the redesigned interface, potential maintenance windows, and more flexible in-app updates. There are also fixes for recording alerts, update recovery, and compatibility with older hosts.
This release updated Next.js and other application, container, and build dependencies.
It also improved what happens when restarting the app temporarily disconnects the dashboard. After retrying an update, ChannelWatch checks the restarted application's version and readiness instead of treating that disconnect as a network failure.
The original restart problem reported in issue #22 remained under investigation. This improved recovery after a restart; it did not establish the cause of that original failure.
Active recordings could lose their scheduled status when they had originally been scheduled more than a day earlier. That could cause a scheduled recording's start notification to be labeled Manual.
ChannelWatch now keeps those active scheduled recordings in tracking so their notifications retain the correct Scheduled label.
This release also added safer update-failure diagnostics while preserving the previous runtime when a restart cannot start.
[image of a scheduled recording notification with its Scheduled label]
The container moved to the official Python Debian Bookworm image, restoring the older x86-64-v1 CPU baseline for AMD64 hosts.
Other changes included compatible dependency updates, a frontend source-map security fix, and a correction to keep channelwatch doctor working with the container's Python environment.
This was a container image update.
The dashboard gained potential maintenance windows for each DVR.
You can filter by minimum duration, day, and time to find gaps between known recordings. The calculation uses the configured timezone and excludes active and scheduled recordings.
[image of maintenance windows showing the filters and available time blocks]
These are suggestions based on the recording schedule, not a guarantee that nobody is using the DVR. Unreachable DVRs, incomplete schedules, and unobserved periods stay marked as unknown. Live TV and recorded-content playback are not predicted, so check the DVR before disruptive maintenance.
This release also separated compatible app updates from newer container image recommendations in Update Center.
This corrected the documented Python image digest in the third-party license inventory. Runtime dependencies and container behavior were unchanged.
Existing v1.4.0 installations could install this correction through Settings > Updates.
Update Center now keeps track of the exact Apply or Retry job through temporary restart disconnects.
Reopening Settings resumes that job, and the dashboard refreshes when the job and the new runtime are ready. This helps avoid losing the installation result or mistaking a restart disconnect for a failed update.
It also distinguishes an installable app update from a newer release that requires a container image.
[image of Update Center showing installation progress or a completed update]
This release added the image-owned launcher and verification support needed for compatible updates to deliver the application and its Python packages together.
Those updates are prepared and verified before activation, with rollback support if the new runtime cannot start correctly.
The Python interpreter, operating-system libraries, Supervisor, and image-owned startup tools still belong to the container image.
v1.5.3 itself required a container image update. However, v1.6.0 now provides a separate app-only update path for the supported v1.4.x images, so those users do not need to install v1.5.3 first.
The interface has been redesigned for desktop, tablet, and mobile.
The dashboard uses more compact cards, with additional details available when opened. Show artwork appears where available, and navigation, settings, dropdowns, and dialogs have been adjusted for smaller screens.
Disk Space and Uptime details stay collapsed until needed. When expanded beside each other, the cards align without stretching a collapsed neighboring card into an empty box.
Settings navigation, loading states, and missing-artwork fallbacks have also been improved.
For updating:
Start the installation manually from Settings > Updates. Automatic installation is disabled for this release.
The update also improves rollback refresh behavior, preserves the installation result when checking again, and shows the recorded preparation error instead of a generic server error.
[image of Update Center offering v1.6.0]
The website and handbook have been redesigned too, with updated app screenshots and layouts for phones, tablets, and desktop.
Website and documentation:
If you're still on v1.1.3 or another image older than v1.4.0:
Use your normal container update process to move directly to the v1.6.0 image. Back up and retain the existing /config volume and any external encryption-key configuration.
You do not need to install each intermediate release.
If you're on v1.4.0, v1.4.1, v1.4.5, or v1.5.3:
Open Settings > Updates, check for updates, and manually install v1.6.0.
This does not mean every future update can avoid a container image change. Updates to Python itself, operating-system libraries, or the image-owned launcher still require the normal container update process.
If you run into a problem, include the app version, your installation method, and what happened. Please keep credentials and private diagnostics out of public replies.
Cheers,
CoderLuii
I've released two updates since the v1.6.0 post above. The current release is v1.6.2.
This release fixed the global notification provider controls. Email and other providers can now be disabled without clearing your saved credentials. Per-DVR overrides remain unchanged.
The Maintenance windows section now appears below Recent Activity and Upcoming Recordings and starts collapsed. You can open it when needed without having it take up a large part of the dashboard.
Activity rows and compact dashboard cards also received alignment fixes for mobile, tablet and desktop. Timeline, diagnostic and filter controls now have clearer labels for screen readers.
The release also includes updated application libraries and refreshed certificate trust data.
Channel logos and program artwork now fit inside their frames in Recent Activity, Watch History and activity details. This fixes wide logos being cropped into narrow poster shapes. Rows also stay aligned when artwork is missing or fails to load.
The diagnostic buttons were sending their display labels instead of the API commands, so the checks were rejected before they ran. Individual checks and Run All Tests now call the correct diagnostics.
Notification diagnostics send sample alerts through your configured providers.
If you're running v1.4.0, v1.4.1, v1.4.5, v1.5.3, v1.6.0 or v1.6.1, open Settings > Updates, check for updates and install v1.6.2 directly.
You don't need an intermediate release or to recreate your container for these app updates. Automatic installation remains disabled, so start the installation manually.
On v1.4.x images, the app-only update keeps the image's existing Python packages. Receiving v1.6.1's certificate trust update on those older images still requires a container image update. Images v1.5.3 and newer can install compatible Python package updates in-app.
Python itself, operating-system libraries and the image-owned launcher still require a container image update when they change. For older installations and migration steps, see the update guide.
The original restart report in GitHub issue #22 remains open. I haven't confirmed its original cause.
Cheers,
CoderLuii
Thanks for this. I was feeling pretty proud of my little status page for my home server until I installed this. 
Any thought to expanding this beyond Channels to include other platforms (Emby, Jellyfin, etc)?
Emby and Jellyfin has their own tool (Jellystat and Tracearr)
Sans for Plex (Tautulli and...again Tracearr)
Theres no need to expand to those tools as they got their own thing
Thanks, that made my day 
For now ChannelWatch stays focused on Channels DVR. But I'm also building HolyArrs, an all-in-one media app for Jellyfin, Plex and Emby, and monitoring like this might find its way in there later. First look at holyarrs.coderluii.dev.
Cheers,
CoderLuii
ChannelWatch v1.6.3 is available now, with follow-up fixes for diagnostic alerts and activity history.
Running diagnostic tests no longer adds sample events to Recent Activity, Watch History or the timeline, or changes live monitoring state. Sample notifications and logs are marked [TEST], including custom templates. Sample channel details and artwork now match instead of borrowing a real channel's logo.
Existing history stays in place. This prevents new diagnostic samples from being added; it doesn't delete samples left by older versions.
The comparison below uses demo data. Both sides start with the same real recording and run a new diagnostic:
Disabled notification tests now show Skipped, with a reason and a separate count. The three alerts disabled by Balanced no longer count as failures, so there's no need to switch to Everything just to make those results green.
Tests respect the checked DVR's settings, including per-DVR overrides. Enabled notification tests still send sample alerts through your configured providers, and genuine connection or delivery errors still show as failures. Tested DVR identifies the server being checked; diagnostics use the first enabled DVR.
Here's the same disabled-alert example before and after, using demo data:
Open Settings > Updates, scroll to the bottom of the Update Center card and click Check for updates. Refreshing the browser only reloads the last saved result; it doesn't run a fresh check. If the check says you're unauthenticated, sign back in and check again.
You can install v1.6.3 directly from v1.4.0, v1.4.1, v1.4.5, v1.5.3, v1.6.0, v1.6.1 or v1.6.2 without an intermediate release or recreating your container. Start the installation manually and wait for the dashboard to reconnect. Automatic installation remains disabled.
On v1.4.x images, the app-only update keeps the image's existing Python packages. Changes to Python itself, operating-system libraries or image-owned startup tools still require a container image update. See the update guide for those details.
@JefferMC also confirmed that his in-app update to v1.6.3 completed and the dashboard restarted, so I've closed issue #22. Thanks for testing it and reporting back.
Cheers,
CoderLuii
ChannelWatch v1.6.4 is available now. This update keeps DVR connection events out of Watch History.
DVR disconnects, reconnects and disk events now stay in Dashboard > Recent Activity. Leave the activity filter on All to see these events. Watch History shows playback and recording activity instead.
Your existing records stay intact. Nothing is deleted, and there's no new setting to enable.
Search, page totals and CSV exports follow the same rule. The client filter also includes devices from older retained history, so you can find their activity without limiting the list to recent devices.
Here's the Watch History change before and after. Both sides use the same demo data:
Here's where DVR connection events appear in Recent Activity, on desktop and mobile. This example uses demo data:
Open Settings > Updates, scroll to the bottom of the Update Center card and click Check for updates. Once v1.6.4 appears, start the installation and wait for the dashboard to reconnect.
Refreshing the browser doesn't run a new update check. If the check says you're unauthenticated, sign back in and check again.
You can update directly from v1.4.0, v1.4.1, v1.4.5, v1.5.3, v1.6.0, v1.6.1, v1.6.2 or v1.6.3 without an intermediate release or recreating your container. Automatic installation remains disabled. On v1.4.x images, the app update keeps the image's existing Python packages.
Thanks for the reports and feedback.
Cheers,
CoderLuii
This looks fantastic! Thanks so much for sharing your great work. Looking forward to updating when I get home.
ChannelWatch v1.6.5 is available now. This update makes Home clearer, makes phones easier to use, and brings back missing watch details.
Home now opens with one line naming the worst problem and the next step. What's on right now comes first. Disk space shows what's left, and a value ChannelWatch can't read shows as a dash instead of 0.
These pictures come from my own DVR, with private details covered by gray bars. Disk space differs because they were taken at different times.
On phones, details open in sheets you can swipe away, and lists and filters take less room. Swipe feel is what a screenshot can't show, so that's the first thing I'd like to hear about.
Watch details are back. VOD duration, episode info and progress show in history again.
Fewer repeat alerts. A low disk warning shows once instead of every few minutes.
Settings save in place, and unsaved changes survive a restart or an expired session. Errors now give the reason and the next step instead of a status code.
Update Center opens with your version and one main button. Roll back now asks first.
Default notification titles changed, like "Failed: The Bear". If a webhook matches on title text, check it before you update. Custom templates aren't affected.
Open Settings > Updates, scroll to the bottom of the Update Center card and click Check for updates. Once v1.6.5 appears, start the installation and wait for the dashboard to reconnect.
You can update directly from v1.4.0, v1.4.1, v1.4.5, v1.5.3, v1.6.0, v1.6.1, v1.6.2, v1.6.3 or v1.6.4 without an intermediate release or recreating your container. Automatic installation remains disabled. On v1.4.x images, the app update keeps the image's existing Python packages.
Thanks for the reports and feedback.
Cheers,
CoderLuii
