Tvheadend

--trace parsers : https://tvheadend.org/projects/tvheadend/wiki/Traces , describe channel / time where the problem occurs

Which subsystems should I trace?

Edit: parser

Here it is:
Bad tune (0kb/s output): https://pastebin.com/KnsWvAM0
Good tune: https://pastebin.com/qn1cptcF

side by side:
(left is bad, right is good)

test 1: http://www.mergely.com/roIrJCW5/
test 2: http://www.mergely.com/aqsK05HX/

The numbers on 'pcr', 'dts' and 'pts' seem to be the "main" difference (on the bad tune they seem to be way off).

Done tests using transcoding stream profiles and it has the same issue.

It looks like clock wrapping issue. The non-working PCR values are around 8589875192 which is 0x1ffff17f8. The wrap mask for the PTS/PCR clock is 0x1ffffffff, so the value 8589875192 means -59400 which is basically OK (DTS is around zero, thus the difference is fine).

So, the question is - where the packets are dropped? It might be probably tsfix. Try "--trace parser,tsfix" .

I just did a quick hack on the code that "fixes" the issue: https://pastebin.com/qVWhQv83
It basically ignores the first packet... my bets go to the dts=0

Will do the tsfix trace and report back.

Thanks!

tsfix log w/o above hack (never recovers):
https://pastebin.com/C0f8iaKP

tsfix log with above hack:
https://pastebin.com/26YP5Kjw

Hi Jaroslav,

Please confirm if this is the correct fix (it seems to solve the issue):

https://pastebin.com/CCsF5yg3

also here: https://github.com/tvheadend/tvheadend/pull/1184

After looking at the inline func pts_diff, doesn't it make more sense to be just this:

https://pastebin.com/e58p2U5r

?

0kb/s output size, that sounds familiar.

Could be related to #5256, pls see there.
At least TVheadend lacks the robustness to detect the problem in both bugs, which it could.

HTH,
/HXZ