Am I missing a setting, or is this a feature request.
I can see the watched status of my recent recordings in Channels DVR, but in DVRDesk only the partially watched ones show a watched status. Some are also missing the channel logo.
DVRDesk v1.12.0
A handful of bug fixes and search improvements in this release.
Watched status bar fix The progress bar on episode and movie cards, list rows, and the detail pane was only appearing for partially watched content — fully watched items showed nothing. That's fixed. Fully watched items now show a solid green bar at 100%, so you can distinguish "never touched," "in progress," and "finished" at a glance across all views.
Search: watched status filtering The Search page now has a Watched Status filter with four checkboxes — Not watched, Partially watched, Watched, and Include Series — all enabled by default. Uncheck any combination to narrow results. TV Series are controlled independently by the Include Series toggle; the other three checkboxes only affect episodes, movies, and library videos.
Search: watched progress in results table Each search result row now shows a small progress bar in the Type column, directly below the type label (TV Episode, Movie, etc.). It uses the same style as the rest of the app — blue/accent gradient for in-progress, green for fully watched. The Type column is also fixed-width so labels never wrap.
As always, download the latest release from the GitHub releases page. Let me know if you run into anything.
That was a bug! Thanks for reporting, please see the update announcement I just posted.
Thanks!
That took care of the watched status.
I still have some recordings not displaying the channel logo.
When I look at the image url, it's not the same as the one that appears in Channels DVR Recordings.
For instance, this was recorded from Smithsonian Channel
The channel logo image url in Channels DVR is http://192.168.1.4:8089/tmsimg/assets/s58532_ll_h15_aa.png?w=360&h=270 which is the Smithsonian logo
The channel logo image url in DVRDesk is http://192.168.1.4:8089/tmsimg/assets/s82695_ll_h15_ab.png?w=360&h=270 which is a single white pixel (1x1) png image
From the recorded file json http://192.168.1.4:8089/dvr/files/3488
Airing.Raw.stationId=82695
{
"ID": "3488",
"JobID": "1781117940-276",
"RuleID": "276",
"GroupID": "25005731",
"Path": "TV/How Did They Fix That/How Did They Fix That S02E01 2023-07-30 Powerships 2026-06-10-1159.mpg",
"Checksum": "aSgveOxIh1OTKvxs_fp4jqCw-cWeB74mSMC9E7Etp64",
"CreatedAt": 1781117940,
"FileSize": 3979291284,
"Duration": 3731.807333,
"Completed": true,
"Processed": true,
"Airing": {
"Source": "tms",
"Channel": "10123",
"OriginalDate": "2023-07-30",
"Time": 1781118000,
"Duration": 3600,
"Title": "How Did They Fix That?",
"EpisodeTitle": "Powerships",
"Summary": "Mike Davidson heads to Brazil, where an offshore crew is setting up giant power ships.",
"FullSummary": "Mike Davidson heads to Brazil, where an offshore crew is racing the clock to set up giant power ships to deliver electricity to a country in desperate need.",
"Image": "https://tmsimg.fancybits.co/assets/p25005731_b_h9_aa.jpg?w=720&h=540",
"Categories": [
"Episode",
"Series"
],
"Genres": [
"Documentary"
],
"Tags": [
"HD",
"Stereo"
],
"SeriesID": "25005731",
"ProgramID": "EP047817620007",
"SeasonNumber": 2,
"EpisodeNumber": 1,
"ReleaseYear": 2023,
"ContentRating": "TV-G",
"Raw": {
"startTime": "2026-06-10T19:00Z",
"endTime": "2026-06-10T20:00Z",
"duration": 60,
"channels": [
"10123"
],
"stationId": "82695",
From http://192.168.1.4:8089/dvr/guide/stations
"82695": {
"type": "Satellite",
"name": "Smithsonian Network HD (Pacific)",
"callSign": "SMITHPH",
"stationId": "82695",
"bcastLangs": [
"en"
],
"preferredImage": {
"uri": "https://tmsimg.fancybits.co/assets/s58532_ll_h15_aa.png?w=360&h=270",
"height": "270",
"width": "360",
"primary": "true",
"category": "Logo",
"text": "",
"tier": ""
},
"videoQuality": {
"signalType": "Digital",
"videoType": "HDTV",
"truResolution": "HD 1080i"
}
},
On second thought that only works for recordings from a channel with a gracenote station ID.
Have to think some more how to handle those channels using non-gracenote ID's to find the channel logo.
I got ahead of myself and pushed before finishing that part. That should be fixed now as well in v1.13. If there actually is no logo to display, it displays the channel number instead. I have a couple of those that are caused by recordings made from channels that I subsequently removed.
1 Like
Awesome. Looking great!
I was wondering about that. I only have HDHomeRun, TVE, and cc4c sources. The cc4c channels are matched to Gracenote, so logos are available for all of those. On the other hand, other sources might not have any kind of logo readily available. How does the Channels client handle it? Maybe it would be useful to have a personal library of logo images? I think the Channels clients could be configured to use that as well...
I know you can create custom channel logos, but not sure how to find those in the API tied to a channel.
I haven't created any.
It appears Channels DVR is using the files json device and channel recorded from
"ChannelNumber": "10123",
"DeviceID": "M3U-PrismCastmacmini",
and looking it up in http://192.168.1.4:8089/dvr/guide/channels to get the logo
"10123": {
"CallSign": "SMITHPH",
"Categories": [
"Documentary"
],
"ChannelID": "smithsonianp",
"DeviceID": "M3U-PrismCastmacmini",
"Genres": [],
"HD": true,
"Hidden": false,
"ID": "smithsonianp",
"Image": "https://tmsimg.fancybits.co/assets/s58532_ll_h15_aa.png?w=360&h=270",
"Name": "Smithsonian Channel (Pacific)",
"Number": "10123",
"Station": "82695",
"Tags": []
},
I assume if you uploaded a channel logo into CDVR it would appear in http://192.168.1.4:8089/dvr/uploads so the above /dvr/guide/channels Image url would be replaced by http://192.168.1.4:8089/dvr/uploads/#/content
I posed that question to Claude and added the link to the instructions for setting up custom channels: Channels Support - Add Custom Channels with M3U Playlists. I also asked if it would be a good idea to create a personal metadata library. Here's his response:
This clarifies the picture significantly. There are three distinct ways a custom channel can carry metadata:
tvg-logo— an explicit logo URL embedded in the M3U#EXTINFline. Channels DVR exposes this aslogo_urlin/api/v1/channels. We already use this first.tvc-guide-stationid— a Gracenote station ID. When set, Channels DVR fetches full guide data AND a correct logo from TMS automatically. This is what drives theImagefield in/dvr/guide/channelsthat we're now using.- Neither — the M3U just has a stream URL and a name. No logo, no guide data. This is the category your deleted channel 9110 and the May 6 recordings fall into — and it's where a metadata library would help.
On the metadata library idea:
It's a real approach but has a scope problem. Channels DVR supports arbitrary streams worldwide — IPTV providers, local streams, IP cameras, hobbyist setups. A library that covers the long tail of global IPTV would be enormous and would need constant maintenance.
The realistic targets for a library are:
- US cable/broadcast networks — CNN, MSNBC, Fox News, ESPN, etc. These are finite (~200 channels), stable, and have well-known logos. A bundled JSON of
{ "CNN": "url", "MSNBC": "url", ... }keyed bytvg-nameorchannel-idwould cover a large portion of US user setups.- Community-maintained sources — there are existing open M3U logo packs (e.g., the
tv-logosGitHub repo at mitchellkrogza/Phishing.Database — actually more relevant is thetv-logoscommunity repo) that map channel names/IDs to logos. DVRDesk could fetch from one of these at startup.The practical approach I'd recommend:
Don't build a library in DVRDesk itself. Instead, expose a user-configurable field in Settings: a URL to a supplemental XMLTV or JSON logo map. Power users who have channels with missing logos can point it at a community logo pack or their own mapping file. The app falls back to the channel number badge (which you already have) for anything not covered.
That keeps DVRDesk lean, gives users control, and doesn't require you to maintain channel metadata. The hard-core IPTV community already maintains these logo packs for exactly this problem.
Want to explore that settings-based approach, or would a bundled US cable channel map be more useful for your current user base?
As I mentioned, I don't have any good test cases for sources that inherently have no metadata, but I think the settings-based solution for IPTV etc., is useful if there is any need for it...
I would just upload a channel logo to Channels DVR if I needed it.
Or add the logo url in the m3u
#EXTINF:-1 channel-id="custom.aa0cfa74-6b50-43ca-8143-ce79a05f96c3" tvg-name="Kitten Academy" group-title="Ambiance" tvg-logo="http://nas-1019:5523/logos/86e71541776894c03a86e06696a199e2.jpg" tvc-guide-description="Kitten Academy is where kittens learn to cat! This channel features videos of and about our foster cats - and the foster failures that live with us forever now.",Kitten Academy
Which comes from https://yt3.googleusercontent.com/ytc/AIdro_nqnFVoqK87F4XbteaL4OiYkasCt4WI2V3IwXQY2Ei8AEI=s160-c-k-c0x00ffffff-no-rj
Works for me!
Keep getting these errors trying to play recordings unless I delete the CDVR video index.
It plays the first frame or couple frames and throws the error.
Any idea what it means?
Playback failed Type: mediaError Detail: bufferAppendError URL: http://192.168.1.4:8389/dvr/files/3109/hls/master.m3u8?encoder=remux
Report
DVRDesk Playback Report
Time: 2026-06-14T22:40:00.124Z
Title: Sheena
File ID: 3109
Prefer remux: on
Manifest URL: http://192.168.1.4:8389/dvr/files/3109/hls/master.m3u8?encoder=remux
Last mutation endpoint: PUT /dvr/files/3109/playback_time/220 (no-body)
Last mutation failure: n/a
Video element: 683x384
Current time: 237s / 3735s
Playback state: playing
Playback rate: 1.00x
Volume: 100%
Buffer ahead: 0.00s
Dropped frames: 1
Decoded frames: 57
Dropped frame %: 1.75%
Ready state: 4
Selected level: 0 (?x? @ 2.75 Mbps)
Estimated bandwidth: n/a
Levels:
0: ?x? 2.75 Mbps v=avc1.4d001f a=mp4a.40.2
1: 682x384 375 kbps v=avc1.64002a a=mp4a.40.2
2: 682x384 500 kbps v=avc1.64002a a=mp4a.40.2
3: 768x432 750 kbps v=avc1.64002a a=mp4a.40.2
4: 1024x576 1.00 Mbps v=avc1.64002a a=mp4a.40.2
5: 1280x720 2.35 Mbps v=avc1.64002a a=mp4a.40.2
Once I delete the CDVR video index it plays fine
DVRDesk Playback Report
Time: 2026-06-14T22:49:48.770Z
Title: Sheena
File ID: 3109
Prefer remux: on
Manifest URL: http://192.168.1.4:8389/dvr/files/3109/hls/master.m3u8?encoder=remux
Last mutation endpoint: PUT /dvr/files/3109/playback_time/409 (no-body)
Last mutation failure: n/a
Video element: 1280x720
Current time: 418s / 3736s
Playback state: playing
Playback rate: 1.00x
Volume: 100%
Buffer ahead: 70.51s
Dropped frames: 2
Decoded frames: 7448
Dropped frame %: 0.03%
Ready state: 4
Selected level: 9 (1280x720 @ 10.00 Mbps)
Estimated bandwidth: n/a
Levels:
0: 682x384 375 kbps v=avc1.64002a a=mp4a.40.2
1: 682x384 500 kbps v=avc1.64002a a=mp4a.40.2
2: 768x432 750 kbps v=avc1.64002a a=mp4a.40.2
3: 1024x576 1.00 Mbps v=avc1.64002a a=mp4a.40.2
4: 1280x720 2.35 Mbps v=avc1.64002a a=mp4a.40.2
5: 1280x720 3.00 Mbps v=avc1.64002a a=mp4a.40.2
6: 1280x720 4.30 Mbps v=avc1.64002a a=mp4a.40.2
7: 1280x720 6.00 Mbps v=avc1.64002a a=mp4a.40.2
8: 1280x720 8.00 Mbps v=avc1.64002a a=mp4a.40.2
9: 1280x720 10.00 Mbps v=avc1.64002a a=mp4a.40.2
It appears this is causing the problem
According to the AI there is not much that can be done for this problem in the app, except to recognize the symptom and suggest rebuilding the index. I asked two questions about this, here are the responses. First question (I also pasted the whole error report):
a user reports: Keep getting these errors trying to play recordings unless I delete the CDVR video index.
Any idea what it means?The
?x?on level 0 is a red herring — remux streams routinely omit resolution metadata from the HLS master playlist, so HLS.js reports unknown dimensions. That's cosmetic.The real problem is
Buffer ahead: 0.00s. The player can't fill its buffer from the server, which causes the stall. The root cause is on the Channels DVR server side: the CDVR video index for that recording is corrupt or out of sync. When the index is broken, Channels DVR can't serve HLS segments correctly for the recorded file — segments either don't arrive, arrive out of order, or can't be decoded. Deleting the index forces Channels DVR to rebuild it from scratch, which is why that fixes it.Notably, your code already has handling for exactly this scenario (see VideoPlayer.tsx:544-549):
// Recordings with fragmented/stale indexes can have buffer holes // wider than the 0.1s default. Raise the threshold so HLS.js // auto-nudges over larger gaps without stalling visibly... maxBufferHole: 0.5, nudgeMaxRetry: 5,But for a fully broken index, those nudges aren't enough — there's no valid segment to nudge to.
Why remux makes it worse: "Prefer remux" selects level 0 (the original stream,
avc1.4d001f), which relies directly on Channels DVR's video index to locate segments. Transcoded levels (1–5) can re-seek the source material more flexibly and are more tolerant of index corruption.Possible improvements to consider:
- If buffer stays at 0 for >~5 seconds while a remux level is selected, automatically fall back to the highest transcoded level (level 5) and show a toast.
- Expose a better error message when this stall pattern is detected, mentioning the CDVR index as the likely cause.
But the actual fix for the user is to rebuild the Channels DVR video index for that recording — WinChannels can't do that on its own since it's a server-side operation.
Then asked if there could be a performance or resource problem causing this since it is a recurring problem. Response:
Yeah, frequent index corruption almost certainly points to a resource problem on the Channels DVR server side, not anything WinChannels can fix. The most common culprits in order of likelihood:
Disk/storage under pressure — If Channels DVR is writing recordings to a slow HDD or NAS while simultaneously serving HLS segments and maintaining indexes, I/O contention can cause index writes to be incomplete or flushed out of order. The index ends up in a half-written state that's not obviously "broken" (no fatal HTTP error) but produces undecodable segment references.
Server was interrupted during recording — A crash, reboot, or process kill while a recording was in progress leaves the index in whatever state it was last flushed to. Channels DVR presumably finalizes the index when the recording ends cleanly; if it doesn't, the index is permanently stale for that file. This would explain why rebuilding fixes it permanently rather than just temporarily.
Simultaneous recording + transcoding load — If the server is recording multiple channels while also running live TV transcodes, it can fall behind on index maintenance under peak load.
The tell for which it is: if the affected recordings all come from specific time windows (overnight, during a sports event, when multiple things record at once) it's load/I/O. If they're random, it's more likely disk health.
For the user: worth pointing them toward checking Channels DVR's server logs around the time those recordings were made, and checking disk health (
SMARTdata if it's a local HDD). The index rebuild workaround is the right fix for already-corrupted files, but if they can't do it via API anymore, they'd need to do it through the Channels DVR web UI directly.As for WinChannels — there's not much to do here beyond potentially detecting the "stuck at 0 buffer on remux" pattern and suggesting they check their Channels DVR server, rather than leaving them with a silent stall.
It would be nice if the index rebuild command was still supported, but I couldn't get a workaround suggestion from Maddox. He didn't respond to this question:
Let me try this a different way, because maybe I'm looking for the wrong solution for the problem. The problem is that some recordings won't play continuously on the web nor in WinChannels (DVRDesk). The playback stalls with a progress circle indefinitely. chDVRuser's solution is to delete the metadata folder for the recording. I'm looking for a more elegant solution than nuking it from orbit.
Thanks for your help!
Maybe you can try soliciting further help from the developers, at least after eliminating performance/resource issues.
Also, it did suggest a potential solution (automatically falling back...). Let me know if you think that's worth trying.
You posted that just as I was replying. Here's the AI's response:
The end user is half right — level 0 is the problem, but not because of
?x?. Unknown dimensions are cosmetic; HLS.js loads segments fine without them.The actual reason level 0 is problematic: it is the remux stream. When "Prefer remux" is on, the level selection logic at VideoPlayer.tsx:618-627 picks level 0 because it has the highest bitrate (2.75 Mbps > 2.35 Mbps for level 5). The remux stream serves the original recording bytes directly, which means it depends heavily on the Channels DVR video index to locate segments. Corrupt index → no segments → buffer stays at 0.
Levels 1–5 are transcoded on-the-fly from the source, so they're more tolerant of a broken index — they don't rely on it the same way.
The
?x?just happens to be visible because remux streams typically don't advertise their resolution in the HLS master playlist. It's a side effect of being on the remux stream, not a cause of anything.What this suggests for the app: when a remux-level stall is detected (buffer stuck at 0 for several seconds), automatically fall back to the best transcoded level and surface a message like "Switched to transcoded stream — recording index may be corrupt." That would let users keep watching without needing to know about CDVR internals.
Want me to implement that fallback?
So, I'll release this fallback solution for you to test momentarily...
Worth a try.
It's not my system and I've brought this issue up many times (having to delete the video index).
Reprocess video (rebuild the video index) doesn't help. Just tried it again to be sure.
I think the side effect of this workaround is that the stream will use more CPU after switching to level 5, so there is still a reason to fix the index. If this works, at least you don't have to fix it before you can watch it.
Who's going to do that? Not the Channels devs. Rebuilding it doesn't fix it. So that leaves what options besides what I've been doing, deleting the video index.
That's what I meant by "nuking it from orbit". There must be some reason that they deprecated the API call that I found references to in discussions with tmm1: New Option on Recording - Regenerate Streaming Index - Channels DVR Server - Channels Community
"Yes, PUT /dvr/files/XXX/m3u8"
But, that returns aa 404 now. I'm not sure if that accomplished the same thing as deleting the whole folder, though.
In either case, you're looking at a DVR feature request.