Tvheadend

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!

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

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.

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.

Maybe this one is related...

https://tvheadend.org/issues/3544#change-18200

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

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.

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.