Bug #4538
closed
Recording of muxes that have alternating stream properties (dvb_teletext), altered mkv behaviour after 4.0.9 to 4.2 update
100%
Description
4.2 works otherwise fine, but I noticed at least one big difference in how it handles recording (with Matroska), especially when I have DVB_teletext streams in my recordings (and the streams change during the recording). I just tested with the latest version of Tvheadend (4.3-334~g7db25fa).
To describe the problem, I first have to describe how the 4.0.9 works for me:
Recordings were set to use Matroska container. This is most suitable, since it keeps the metadata, which I then extract with a script to Kodi's .nfo (XML) format. On MOST channels, I would get just one file, named something like "Lego Ninjago.2017-04-22.08-10.mkv". But on some free channels I get several files, named "Lego Ninjago.2017-04-22.08-10.mkv", "Lego Ninjago.2017-04-22.08-10-1.mkv" and "Lego Ninjago.2017-04-22.08-10-2.mkv". It didn't take long to see that the first and the last files were small (padding in the beginning and end of the recording), and only the biggest file included the actual program I wanted to record. The reason for this clipping is (most likely) because of the stream configuration changes. Especially in my country and setting there are often a DVB teletext streams (yes, they use those here) added or changed. So as a result of this "clipping", all of the files have non-conflicting sets of streams, and as a bonus, the actual program has virtually no padding at all. So this old behaviour is both predictable and useful.
The new behaviour: I get only one big mkv file, EVEN if the stream configuration changes. When watched with a media player (MPC-HC, for example), it starts normally but then freezes at the beginning of the actual program. I tried to convert the file with ffmpeg (as I normally do for all of my recordings). Ffmpeg bursts out stream related errors at the same timespot where the program should start. And the resulting file freezes during playback, when I reach the spot where the actual program would start (about Ninjago, let's just say it was an example).
So the problem seems to be this (I'm still just guessing): Old version handled stream configuration changes by merely clipping the recording to several files. This caused some problems for TVHeadend, for example if I wanted to view the recording directly using the Recorded Programs database (it would only play the last small padding file), but this was a non-issue for me (since I only watch the ffmpeg-self-converted files using Kodi).
Now the new version records everything in the same file, even if the stream configuration changes cause (apparently) severe issues for the file, at least mkv container (which I still prefer to use).
Is there something I'm overlooking, can the old behaviour be restored with a configuration option? I did not find suitable options in the Recording Config Tab in the new 4.2 version. The new webtv-h264-aac-matroska seems to have completely different output, not sure if it would be applicable.
If the new behaviour is otherwise preferable by developers, could it, maybe, pretty please, be possible to add a checkbox named "Restart recording at stream change" (or similar)?
Updated by 
Updated by 
Updated by 
Updated by 
Updated by