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.
)