DVRDesk a simple Windows and Linux client for Channels

Playground Hacks
#116

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

#117

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.

#118

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.

#119

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.

#120

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.

#121

Maybe it's not a feature request. If rebuilding the index doesn't fix the problem but deleting the folder does, then it may be a problem with other files in the folder:

Right, "the index" is probably a simplification of what's actually being deleted. In Channels DVR, the metadata folder alongside a recording typically contains more than just the seek index — things like cached codec/stream analysis, segment timing maps, commercial detection results, thumbnails, and possibly a pre-built HLS segment manifest. When the server does an API "rebuild index" it may only regenerate the seek index file, leaving the other stale/inconsistent metadata in place. Deleting the whole folder forces a clean rebuild of everything from the raw video bytes on next access.

The transcoded stream sidesteps all of it because it re-reads and re-encodes the source file directly, ignoring whatever is in the metadata cache. That's exactly why our fallback works — it's not that transcoding is "better quality" for this file, it's that it bypasses the corrupted metadata entirely.

For this user specifically, the practical takeaway is: our auto-fallback means they no longer need to delete anything to watch the recording, but the underlying metadata corruption in Channels DVR is still there. If they want a permanent fix for that file (seeking performance, commercial skip accuracy, etc.), deleting the metadata folder is still the right move — and since the Channels devs apparently won't expose an API to do it cleanly, it's a manual operation on the server filesystem.

So, if this isn't a resource issue causing something in the metadata folder to be incorrectly written in the first place, there this could be a bug that they need to fix. Or, it's a feature request to provide a mechanism to rebuild all of the folder's contents (or just the problematic part if that can be isolated)

If you care to track this down, try removing one file at a time to see the effect.

#122

The new version is live now

#123

Yah, since they started fingerprinting recordings they changed to API to
PUT /dvr/files/<file#>/fingerprint
Accessed by the Option Reprocess Video
Reprocess Video

It rebuilds the video index.

#124

Incorrect. It does not rebuild it.

#125

As far as the devs are concerned, there is no problem (it becomes a "me" problem) unless others report it, and then it's unsupported because it's not a supported client problem.

It's already in there

Thank You. It's working and falls back to transcoding as you said.
When I delete the video index it has to transcode anyway. Now I don't need to delete the video index (but I will as they are useless to me and just take up space :grin:)

#126

OK, well that's something! Another thing you could do is to move the metadata folder and then compare the old files to the new ones that are created to see what changed. If you can isolate a specific file, and the data in the file that's causing the problem, maybe the devs would be inclined to fix it.

#127

you mean always, or just the first time? If always, what happens if you delete the folder then use the reprocess video command?

#128

It doesn't happen on every recording (just most of them).
When it does happen, if I delete the video index and recreate it, it still fails.
I started noticing this years ago using the DVR web UI player.
I'm surprised nobody else has brought it up (or maybe they didn't spend the time to dig as deep).

#129

the resolution is very odd (nintendo ds?) so it doesn't seem to matter which source the recording was from?

I mainly use dvrdesk for checking live souces, but just now i tried some recordings from different sources and haven't encountered the error. on 1.11.0 and 1.14.0. although both versions transcode recordings from hdhr, while ah4c recordings do the simple remux.

yea, don't really ever expect the web ui to play. haven't payed attention in a long time as to which recordings work and don't.

#130

I though it odd also, but that's supposedly coming from Channels DVR for a recording (not Live).

That one was a 1280x720p@30fps recording from the FrndlyTV channel MeTV+
I've also seen it happen on HDHR Prime recordings from my PBS station ([email protected]).

If you want some stats, let me know what you want me to keep track of when it happens again.

The video index file I'm talking about is named stream.m3u8 in the Metadata/file# folders

#131

the only thing i can think of is just the timing of the recording catching a low res image during a keyframe at the beginning.
otherwise these advance settings come to mind, using any of these?
Experimental Remote Live TV Segmenter
Use HEVC for transcoding
Web Player Adaptive Streaming
I have all these off, so idk

#132

That Video element: 683x384 resolution came from the DVRDesk Copy Report button.
You would have to ask @jay343 where that comes from.

I don't have any Advanced Experimental settings enabled.

#133

so I watched the cdvr log while playing recordings from dvrdesk. ah4c recordings show no entry (remux) and one of my local news recordings shows this

2026/06/14 23:04:11.181178 [HLS] ffmpeg: file41844-ip10.0.0.35:  [mpegts @ 0000021397569980] Packet corrupt (stream = 1, dts = 4922541299), dropping it.
2026/06/14 23:04:11.181178 [HLS] ffmpeg: file41844-ip10.0.0.35:  [mpegts @ 0000021397569980] Packet corrupt (stream = 2, dts = 4922541299), dropping it.
2026/06/14 23:04:11.182822 [HLS] ffmpeg: file41844-ip10.0.0.35:  [mpegts @ 0000021397569980] stream 2 : no PTS found at end of file, duration not set
2026/06/14 23:04:11.183356 [HLS] ffmpeg: file41844-ip10.0.0.35:  [vost#0:0/h264_mf @ 00000213981a5000] -enc_time_base -1 is deprecated, use -enc_timebase demux
2026/06/14 23:04:11.186124 [HLS] ffmpeg: file41844-ip10.0.0.35:  [aost#0:1/aac @ 000002139821e880] -enc_time_base -1 is deprecated, use -enc_timebase demux
2026/06/14 23:04:11.187770 [HLS] ffmpeg: file41844-ip10.0.0.35:  [aost#0:2/aac @ 0000021397572700] -enc_time_base -1 is deprecated, use -enc_timebase demux
2026/06/14 23:04:12.145346 [HLS] ffmpeg: file41844-ip10.0.0.35:  [h264_mf @ 00000213981a52c0] stream format change

I do have a bad antenna signal now that the trees are full of leaves, so many local channels recordings have glitches, and I was hoping it could shed some light. I'll have to see in the morning when the leaves are wet, and pixilation goes crazy.

#134

have you tried copying one into the imports dir and seeing if there's any difference? not sure there would be or what it'd tell us.

#135

If I did that it wouldn't have a video index, so would transcode just like if I had deleted the video index.

Just seems like the CDVR recording timestamp rewriter and remuxing is tuned for the Channels clients (obviously).

I've had to remux some recordings because their recording timestamp rewriter caused timestamp issues.

This has been going on for years, so I don't think anything will get done because I'm trying to play the recordings in unsupported clients like a browser or DVRDesk.

All of the problem recording files play fine in VLC and my Video Editor.