Bug #1724

Recordings are segmented, and only the last portion is played back

Added by Diego Rivera about 10 years ago. Updated about 10 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Found in version:
3.4 (OpenELEC add-on)
Affected Versions:


I've been making recordings normally, and the shows seem to be recorded properly. However, the recordings are segmented and only the last segment is played back when playback is requested.

One upside is that the segments are either "show" or "commercials" - meaning that it's fairly easy to skip the commercials. This seems to be an issue with how the TV transmission is coming in (the TV station changes resolution, I think, or "something", when it switches to commercials). However, the quality of the recordings is fine. Each segment has a _0, _1, etc. number appended to the name, to help identify the order in which they should be played back.

This is all fine and dandy, except only the last segment is played back (either by XBMC, or by request through the TVH UI or even the TVHGuide Android app). Accessing the files directly works fine.

Ideas? I'm an experienced developer (with decent C/C++ skills), and can put some time to this if you like. However, I'd like your input on to how the feature is expected to work and what the acceptable solutions could be for cases like this. In particular - the commercial skipping feature: is that even a part of TVH as a PVR? How is it supposed to work?



Updated by Adam Sutton about 10 years ago

This is not a big, its intended operation. The problem is that it's a limitation of MKV files.

How to deal with stitching things back together in this situation is already covered elsewhere, though until I can find it I'll leave this issue open.

The best solution is to record using TS format.

Oh and ignore the commercial skipping stuff, it should have been removed from 3.4 as it doesn't actually do anything (except for one very special case on one channel in Sweden) it was test code.



Updated by Diego Rivera about 10 years ago

I've been spelunking around the code, and it appears that there is a widespread assumption that DVR entries will only contain a singular file. This is evidenced by the dvr_entry structure which contains a single filename field, as well as the code that services the "/dvrfile/?" requests which seeks to open that file and return the stream for service over HTTP.

I did notice many small *.mka (audio-only) files which sort of "fit" between the "program" chunks and the commercial chunks - could be a byproduct of how the stream is being received. However, the fact remains: TVH clearly supports capturing a single source (even if it ends up being many streams) into multiple targets. It would seem natural that it would support playback of those multiple captures as a single unit as well.

However, having looked at the code, this doesn't appear to be a quick fix. I'll keep reading to see what else I learn. Maybe there is a quick fix that I'm just not seeing out of unfamiliarity with the code.


Updated by Diego Rivera about 10 years ago

Fair enough - I'll try TS recordings. Perhaps adding the option of "execute script post-recording" somewhere, to allow for such "stitching" to be customizable? That could also help implement other things like "Notify recording status over SMS/EMAIL/CHAT/whatnot"...

How does that sound? That shouldn't be too hard to implement I think...right?


Updated by Diego Rivera about 10 years ago

Interesting: the TVH version packaged with OpenELEC doesn't include an MPEGTS option for recordings - only Matroska. I guess I'll have a word with them boys :)


Updated by Diego Rivera about 10 years ago

And don't I feel sheepish - there's the "post-processor" command option here...

On a side note, with the info from here ( I should be able to come up with something workable, which I'll post here for someone else's future reference.


Updated by Adam Sutton about 10 years ago

The fact that TVH currently creates multiple files is kind of a by-product of trying to stop MKV recording completely losing stuff and failing due to changes in the stream make up. But you're right that currently TVH is also geared towards one file per recording, for a variety of reasons.

I have plans, but never seem to find the time, to redo the DVR code and this would hopefully address these issues. However if there's one thing I've learnt in the past 18 months, its that recording to TS is a much better option! Though Andreas will probably shoot me for saying that. I only move stuff to MKV as a manual postproc when its stuff I want to keep (and I usually cut top/tail off as well).

OE should now include 3.4, though I don't use that so can't comment.



Updated by Richard Lloyd about 10 years ago

This is similar to the bug (OK, "feature request") I reported last year as issue 1242 at

I've learned to never restart tvheadend when it's recording, that's for sure :-) The bug part of it is indeed that you can't access the earlier parts and, even worse, can't delete them from the UI (you have to delete them from the command line manually, but you might not know they're there of course).


Updated by Diego Rivera about 10 years ago

TVH on OE is v3.4. However, it lacks the "store as MPEGTS" option for recordings - the only container listed (supported?) is Matroska. I'll have to look into that.

Also available in: Atom PDF