Bug #3855
tvheadend seems confused about DVB stream properties changing during a recording
0%
Description
Tvheadend does not handle gracefully situations where DVB stream properties change during a recording. The behaviour varies according to the recording settings, but especially with .mkv the current behaviour is quite unusable, and even with .ts there are problems.
With .ts, the recording will be split at each change of the stream - and depending on the broadcast, this might be at the first translated line / subtitle (which might be well into the actual broadcast, since the actual subtitle stream does not start earlier). There are various other problems related to this splitting, most notable being the fact that no frontend (that I know of) has no way of choosing which split to play, and usually chooses the wrong one. There are situations, where the whole desired recording will not be in a single file!
With .mkv, I've previously got split files as with .ts, but with current GIT I cot a weird interleaved file (wich seems to confuse most players). For more details about the bronken .mkv behaviour, and for discussion not relevant to actually fixing this bug, see: https://tvheadend.org/boards/5/topics/21288
Attatched is a muxdump containing finnish public broadcasting company (YLE) channels (unscrambled). I will try to provide a dump during which there should be actual change in programme (and subtitle/audio/video streams).
Files
History
Updated by Wild Penguin over 8 years ago
Updated by I seem to have problems attaching a dump into this bug (the file does not upload trough this form on Firefox and fails eventually with "Request Entity T" - the message seems truncated). Please PM me with instructions what I can do to upload the dump!
Updated by Mark Clarkstone over 8 years ago
Updated by Ville Aakko wrote:
I seem to have problems attaching a dump into this bug (the file does not upload trough this form on Firefox and fails eventually with "Request Entity T" - the message seems truncated). Please PM me with instructions what I can do to upload the dump!
"Requested Entity Too Large" basically cloudflare doesn't allow files larger than 100Mb, you can bypass this via: http://pam.exsilia.net/issues/3855
Updated by Wild Penguin over 8 years ago
I noticed the description I added to the dump file above can not be seen. It should contain a few minutes of a MUX containing Yle TV1 HD and Yle TV2 HD (unscrambled) and a few scrambled channels.
Updated by Jaroslav Kysela over 8 years ago
Updated by Note that most broadcasters converts the sources to fixed A/V formats. The only thing I noted for channels received in my area is that AC3 audio might change from 2.0 to 5.1 etc.
About frontends: You may check the 'Clone scheduled entry on error' in the DVR config to get multiple DVR entries per splitted recordings. Yeah, the label/description might be improved.
.TS format: If you use 'pass' output (streaming profile), you should not see splits. The .TS file carries all info (basically - it should have all received info without any modifications except filtering of other services). Note that 'avlib/mpeg-ts' output is different and you'll get splits.
.MKV format: The split is necessary - this format does not allow to change A/V parameters at runtime. If you see a bad timing for some streams then it's a bug. We have some bug reports for subtitle timing, but I was not able to correlate times for some channels with DVB subtitles with the audio track.
Updated by Bengt Madeberg over 8 years ago
Updated by Maybe this one is related...
Updated by Wild Penguin over 8 years ago
Jaroslav Kysela wrote:
Note that most broadcasters converts the sources to fixed A/V formats. The only thing I noted for channels received in my area is that AC3 audio might change from 2.0 to 5.1 etc.
This may be the case for some broadcasts, but I've already established this is not the case for broadcasts I'm recording. At least the subtitle and audio channels are changing (everything not in Finnish is subtitled and almost nothing is dubbed, which means the audio and subtitle track will change). I'm not 100% sure, but I think that the HD channels do not transcode SD material - which also means the video format also sometimes changes (I'm not certain what material is in SD, as most is in HD, so this is a bit difficult / time-consuming to confirm).
I'm positive that at least some commercial channels, they do not transcode old 4:3 TV series (which means the format will change at every commercial break).
About frontends: You may check the 'Clone scheduled entry on error' in the DVR config to get multiple DVR entries per splitted recordings. Yeah, the label/description might be improved.
I can not find this setting (it should be in Configuration -> Recording -> Digital Video Settings ?) but I've since reverted to 4.0.9, maybe it doesn't have the setting (whereas the GIT does have it). I had a memory leak with current GIT that made the backend useless for me.
.TS format: If you use 'pass' output (streaming profile), you should not see splits. The .TS file carries all info (basically - it should have all received info without any modifications except filtering of other services). Note that 'avlib/mpeg-ts' output is different and you'll get splits.
Are you sure, since with 4.0.9, I do get splits. I believe they are at the stream changes, and these are not transmission errors (I could make another muxdump to be sure, see below).
.MKV format: The split is necessary - this format does not allow to change A/V parameters at runtime. If you see a bad timing for some streams then it's a bug. We have some bug reports for subtitle timing, but I was not able to correlate times for some channels with DVB subtitles with the audio track.
With current GIT, I did not get a split, but the weirdly interleaved file I described above. With non-GIT, I previously did get split records with MKV. But this is probably a separate issue/bug, indeed.
I've thought about making another mux-dump during these "stream changes" I've described above (from the very same mux - and while recording and getting the dump during a split). Would that help, or should I do that and post the dump here? (it may take a while since I need to be "sitting" right next to the DVR computer, monitor the transmission and try to take the muxdump at exactly the right time, or the file size will get huge very fast).
Updated by Wild Penguin over 8 years ago
I took a look into this and it seems I was mistaken:
Wild Penguin wrote:
.TS format: If you use 'pass' output (streaming profile), you should not see splits. The .TS file carries all info (basically - it should have all received info without any modifications except filtering of other services). Note that 'avlib/mpeg-ts' output is different and you'll get splits.
Are you sure, since with 4.0.9, I do get splits. I believe they are at the stream changes, and these are not transmission errors (I could make another muxdump to be sure, see below).
I do not get split files with .ts after all (I got a single .ts file among dozens that was split, and that seems like it was caused by reboots caused by other reasons).
I was confused by the fact that for some reason the "pass" profile change was not saved / was reset, and I got .mkv files and was sloppy at checking the file ending!
However, I seem to get a weird memory leak if I use .ts (='pass') format even with 4.0.9. I will investigate and report back here.
Updated by Wild Penguin over 8 years ago
Ok, this is a bit embarassing.
I've confirmed that I did not get split .ts because of stream changes, as I've described in the report. I've got them occasionally for other, obvious reasons (rebooting etc.), so mostly this bug report is invalid and could be closed as such.
You may still want to keep this bug report open to track the issues with split .mkv (and, the cases when it is not split as it should). But I think those issues are already known, and partly the issue should be handled by the KODI frontend (?), and I'm not sure this is the right tracked for that.