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