Tvheadend

Which muxer ? Matroska ? Live streaming is OK ?

Live stream is no problem.

Recording Stream Profile is matroska.

The problem occurs with several muxes, dutch, on Astra3 12187.5 (NPO 3 HD), 11856 (RTL 4 HD)

Some versions before, 3.9.2112~gfa22f18, around 18-11-14, the sound is terrible lot of echo.

And live stream using matroska muxer ?

Default stream profile is pass. Is this what you mean by live stream settings?

After switching to the latest (broken) version and putting the default stream to matroska the live stream is Fine also, no problem at all.

Switching the recoding profile to pass the recording result is fine now, and after switching to matroska the reording is bad again.

It seams that the matroska muxer is not working for me anny more with recodings but seems not have effect on live TV (live stream)

New information, it looks like that I don't know the half of the functionality of tvheadend ;)

In "access entries" it is possible to select a streaming profile, in my case it was empty. After selecting matroska I have no live stream picture at all. With "pass" I experiance no problems.

<b>Conclusion:<b> On my system it is not possible to use streaming profile "matroska" for both DVR and Live TV

I can confirm these problems. I also come from a old version (3.9.1531). Recording profile is also matroska. No problem on my old version (i actually switched back after trying out a version from yesterday). Both tuners recordings are fine.

With the newer version it seems that one of the tuners recordings is (probably) good, a parallel second one is bad (or live-tv plus recording in second tuner). Also jumps around and not playable at all. Live-TV is no problem. Actually I cannot guarantee that one recording of my tuners is good and using a second one parallel is bad, I just think i had a good one after taking a look into that issue. Had to switch back too soon due to the dropped women acceptance factor :-\

OK, Any FTA channel with this issue ? I cannot receive the mentioned channels. My H264 channels are OK with the matroska container (tested with VLC, mplayer, ffplay)..

Perhaps, you may attach a .TS stream sample (saved using 'wget -O <file>.ts <URL_from_the_play_link_in_GUI_service_or_channel>' (use 'pass' profile as default).... I will try to simulate the input here using this file.

Cca 60 seconds..

I found another little issue in the H264 parser: https://tvheadend.org/projects/tvheadend/repository/revisions/ea23369c5d4ab578c54f86fa811b94e2467d1eca

v3.9-2145-gea23369

The .mkv file can be played with VLC without any problem.

For playback in XBMC i use the pvr.tvh plugin.

Hmmm. I can reproduce using this .TS file, but I went to v3.9-1799-g97b593c and the problem is there, so I think that it's an old issue....

I have the same problem with matroska (mkv) recordings, at least with (some/all?) HD Plus channels (checked for "RTL HD"), but not with (all?) other HD channels (checked with "ServusTV HD Deutschland", "KiKA HD"). The problem was definitely introduced with 3.9.2127.

What can I do to help debugging?

Kai Sommerfeld wrote:

Attached is an mkv I've just recorded with 3.9.2127 (~50 secs., RTL HD). This mkv cannot be played with Kodi latest master. It jumps, stutters, ends after 5 secs or so. Same station, same event recorded with with 3.9.2126 works fine in Kodi.

Indeed the file is bogus: mkvalidator /tmp/Team\ Wallraff\ -\ Reporter\ pr_fen\ nach.2014-11-24.22-15.mkv > /tmp/errors 2>&1

more /tmp/errors
WRN0C0: First Block for video track #1 in Cluster at 98481 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 2274770 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 6831736 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 11284106 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 13864324 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 14787853 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 19297419 is not a keyframe
WRN0C2: The timecode of the Cluster at 20076080 is not incrementing (may be intentional)
WRN0C0: First Block for video track #1 in Cluster at 20076080 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 22111996 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 26144286 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 26668342 is not a keyframe
ERR0B2: Block at 671504 is using an unknown track #0
ERR0B2: Block at 672938 is using an unknown track #0
ERR0B2: Block at 682614 is using an unknown track #0
ERR0B2: Block at 700082 is using an unknown track #0
ERR0B2: Block at 735379 is using an unknown track #0
ERR0B2: Block at 743220 is using an unknown track #0
ERR0B2: Block at 744654 is using an unknown track #0
ERR0B2: Block at 786036 is using an unknown track #0
ERR0B2: Block at 788572 is using an unknown track #0
ERR0B2: Block at 798736 is using an unknown track #0
ERR0B2: Block at 806342 is using an unknown track #0
ERR0B2: Block at 807776 is using an unknown track #0
ERR0B2: Block at 809210 is using an unknown track #0
ERR0B2: Block at 846141 is using an unknown track #0
ERR0B2: Block at 857127 is using an unknown track #0
ERR0B2: Block at 858561 is using an unknown track #0
ERR0B2: Block at 866167 is using an unknown track #0
ERR0B2: Block at 867601 is using an unknown track #0
ERR0B2: Block at 869035 is using an unknown track #0
ERR0B2: Block at 876845 is using an unknown track #0
ERR0B2: Block at 916569 is using an unknown track #0
ERR0B2: Block at 924281 is using an unknown track #0
ERR0B2: Block at 961970 is using an unknown track #0
ERR0B2: Block at 979852 is using an unknown track #0
ERR0B2: Block at 981286 is using an unknown track #0
ERR0B2: Block at 982720 is using an unknown track #0
ERR0B2: Block at 990326 is using an unknown track #0
ERR0B2: Block at 1072540 is using an unknown track #0
ERR0B2: Block at 1110160 is using an unknown track #0
ERR0B2: Block at 1131880 is using an unknown track #0
ERR0B2: Block at 1154500 is using an unknown track #0
ERR0B2: Block at 1155934 is using an unknown track #0
ERR0B2: Block at 1163540 is using an unknown track #0
ERR0B2: Block at 1211018 is using an unknown track #0
ERR0B2: Block at 1233303 is using an unknown track #0
ERR0B2: Block at 1250236 is using an unknown track #0
ERR0B2: Block at 1268106 is using an unknown track #0
ERR0B2: Block at 1269540 is using an unknown track #0
ERR0B2: Block at 1270974 is using an unknown track #0
ERR0B2: Block at 1330775 is using an unknown track #0
ERR0B2: Block at 1332209 is using an unknown track #0
ERR0B2: Block at 1365513 is using an unknown track #0
--More--(4%)

To make it a little bit more clear: I do not have any problmes with Live TV playback or playback of ts files created by tvheadend.

I do only have problems with playback of mkv created by tvheadend. Not all channels are affected, though. But the affected channels reliably bomb!

I sent fernetmenta one of these mkvs and he believes that the mkv is seriously broken. Lots of errors from ffmpeg when trying to play it in Kodi.

The problem still exists with latest tvheadend (3.9.2161 at the moment of this writing) and can 100% reproduced here.

The keyframe error is fixed in v3.9-2163-g448b0a4 . Thanks for the mkvalidator tip. Other errors are gone (at least for the .TS file from Meindert), too...

Please, report any other issues...

Jaroslav Kysela wrote:

The keyframe error is fixed in v3.9-2163-g448b0a4 . Thanks for the mkvalidator tip. Other errors are gone (at least for the .TS file from Meindert), too...

Please, report any other issues...

The keyframe errors were there before (for years) and did not harm (just warnings anyway). The errors "Block at 1131880 is using an unknown track #0" reported are probably the real reasons for the problems.

NB : even when mkvalidator does not bark, the file may still be bogus but at least it simple to test.

Eric Valette wrote:

Jaroslav Kysela wrote:

The keyframe error is fixed in v3.9-2163-g448b0a4 . Thanks for the mkvalidator tip. Other errors are gone (at least for the .TS file from Meindert), too...

Please, report any other issues...

The keyframe errors were there before (for years) and did not harm (just warnings anyway). The errors "Block at 1131880 is using an unknown track #0" reported are probably the real reasons for the problems.

NB : even when mkvalidator does not bark, the file may still be bogus but at least it simple to test.

I don't see any unknown track errors in my tests, so it's difficult to say from where they come. There are no changes in the MKV block builder in last months.

Jaroslav Kysela wrote:

I don't see any unknown track errors in my tests, so it's difficult to say from where they come. There are no changes in the MKV block builder in last months.

I Can only propose to test mkv recordings on HD channels when times permit. Reconfig is usually quite painfull so be patient.

I tried with 3.9.2165~g3579d04 and the result is differend but the recording can't be played.

Could you record both TS and MKV at the same time and give me these examples to check ? If I pass the All Stars 2_ Old Stars.2014-11-22.20-00.ts through --tsfile option I can generate valid MKV from this stream.

I only noted, that mplayer (which also uses ffmpeg for decoding like XBMC) requires bigger input buffers (like "-cache 20480"). Otherwise I also see artefacts and decoding errors are reported. It seems to me that ffmpeg libs are not handling these situations optimally (these H264 are probably more complex that the standard caching can handle).

At the same time, anny idea how to do that ?

Jaroslav, honestly, I'm pretty sure that the problem originates in the changes you did in the commit for 2127. Could you by any chance doublecheck that changes, please. I just tried 2165 and mkvalidator still complains massively about "ERR0B2: Block at xxxxxxx is using an unknown track #0". Those errors are not present with mkvs generated by 2126, for the same channel. Again, no problems at all with 2126. Ic an reproduce that.

BTW: If there are no problems with .ts, how should supplying .ts files help to debug this problem? Just curious.

Jaroslav, one more comment to convince you to take a deeper look at the changes of 2127: mkvalidator since this commit complains about "usage of unknown track" and in 2127 you did some modifications to src/muxer/tvh/mkmux.c, function mk_build_tracks() and mk_mux_write_pkt(). Could this changes probably be related to the broken mkvs?

It seems that my changes (optimizations) discovered another hidden bug which was there for years.. Could you try v3.9-2167-g39a4db4 ?

Meindert Oldenburger wrote:

At the same time, anny idea how to do that ?

Two terminals, two wget commands, you can choose profile using the HTTP GET variable profile= something like:

http://<...playurl...>&profile=pass
http://<...playurl...>&profile=matroska

In version 3.9.2167~g39a4db4 no improvements conserning matroska profile.

In DVR profiles i made two profiles "pass" and "matroska" with coresponding streaming profiles

But after entering below commands it seems that I become two identical files?! (head TESTFILE.ts is like head TESTFILE.mkv)

wget -O TESTFILE.ts http://core2:9981/play/stream/channel/5b6b5fca17373256736c4b22c9fd5d46&profile=pass &
wget -O TESTFILE.mkv http://core2:9981/play/stream/channel/5b6b5fca17373256736c4b22c9fd5d46&profile=matroska

During above test I also have two streaming profiles with identical names and profile configured.

Meindert Oldenburger wrote:

But after entering below commands it seems that I become two identical files?! (head TESTFILE.ts is like head TESTFILE.mkv)

wget -O TESTFILE.ts http://core2:9981/play/stream/channel/5b6b5fca17373256736c4b22c9fd5d46&profile=pass &
wget -O TESTFILE.mkv http://core2:9981/play/stream/channel/5b6b5fca17373256736c4b22c9fd5d46&profile=matroska

This is wrong. If you remove ?title=.... (or you use direct service play link) you should use ?profile=pass and ?profile=matroska...

Also note that the '&' char must be escaped for shell like '\&'..

The correct commands should be:

  wget -O TESTFILE.ts  http://core2:9981/play/stream/channel/5b6b5fca17373256736c4b22c9fd5d46?profile=pass &
  wget -O TESTFILE.mkv http://core2:9981/play/stream/channel/5b6b5fca17373256736c4b22c9fd5d46?profile=matroska

OK. v3.9-2168-g60574bf . I hope that this is really the right fix..

It seems to be fixed. Thanks a lot.

Maybe not the place to ask, but could you reopen issue #2501 ?

Kai Sommerfeld wrote:

Yeah, fixed. Thx.

mkvalidator report no errors, only two warnings:

./mkvalidator ../Videos/Mario\ Barth\ deckt\ auf.2014-11-26.20-15.mkv
WRN0C0: First Block for video track #1 in Cluster at 23080147 is not a keyframe

It's ok. The solution might be to drop all video frames until first keyframe, but it's better to start ASAP.

WRN0B8: Track #3 is defined but has no frame

| + A track
|  + Track number: 3 (track ID for mkvmerge & mkvextract: 2)
|  + Track UID: 3
|  + Track type: subtitles
|  + Lacing flag: 0
|  + Codec ID: S_DVBSUB
|  + Language: ger
|  + CodecPrivate, length 4

No DVB subtitles in the broadcast ?

All seems good to me...