Project

General

Profile

Recording of muxes that have alternating stream configuration, altered mkv behaviour after 4.0.9 to 4.2 update.

Added by Henrik Söderström over 7 years ago

Congratulations for getting the 4.2 stable to public! I've used version 4.0.9 for about a year, and I've been happy with it, most of the time. Some unexplained shortcomings, like random error bursts in DVB-C (only one I'm using) and very random server hangings. And the fact that I'm running the whole system on a virtual machine is great for my HTPC-setup.

So, I wanted to try the 4.2 stable version. It seems to have all the previous functionality, plus some great extra. But one setup-breaking change became apparent during my initial testing. 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 then declares that the conversion failed. So the recording fails for many (not all) of the shows I'm interested in (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)?


Replies (1)

RE: Recording of muxes that have alternating stream configuration, altered mkv behaviour after 4.0.9 to 4.2 update. - Added by Mark Clarkstone over 7 years ago

Just out of interest, have you tried the "Use EPG running state" option in DVR Profiles?

And, you may want to open an issue :p

    (1-1/1)