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.
@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
@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
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.
As long as I'm giving feedback:
- 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.
- 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.
1 Like
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:
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
@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
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.
@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
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.
@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
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
@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.
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 failedmessage 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
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.
ChannelWatch v1.0.9 through v1.1.2
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.
v1.0.9
This release focused on activity reliability, safer DVR removal, and Settings and Dashboard behavior.
- Activity and notifications: Health changes and recording outcomes remain pending if activity storage or the notification queue cannot accept them. ChannelWatch can retry that work, including after a restart, instead of silently losing the event.
- Safer permanent DVR removal: Storage and settings failures are reported, and interrupted cleanup can recover. Unreadable recovery data is preserved instead of being discarded during deletion.
- Settings navigation: The visible tab now stays aligned with the browser address and Back/Forward navigation while preserving unsaved settings.
- Keyboard and screen reader support: Expandable Settings sections, notification controls, and the restart dialog received accessibility fixes. Notification text contrast was also corrected in both themes.
- Dashboard freshness: If system, recording, or activity data cannot refresh, the Dashboard shows a warning for the affected data while retaining the last available information. Each warning clears when that data recovers.
v1.1.0
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:
- Accessible Timeline details: The Timeline now offers an expandable table with exact counts for the selected series and local time intervals, including repeated hours when daylight saving time ends.
- Mobile navigation: Keyboard focus stays inside the open menu and returns appropriately when it closes or navigation changes.
- Long-running resource use: Inactive API rate-limit records are cleared, and retained records are bounded without removing active rate limits.
- Update catalog reliability: Published release entries are retained so compatible intermediate releases aren't dropped from the update catalog.
- Support and release maintenance: Reporting forms explain diagnostic privacy more clearly. Release checks, version information in distributed source and license materials, and security support documentation were corrected. A build dependency was also updated to address two upstream security advisories.
v1.1.1
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.
v1.1.2
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.
Updating
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:
- X.Y.0: Container image update.
- X.Y.1 through X.Y.9: Signed updates through the Update Center on that image line.
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.