Help with IPTV and Continuity counter error

Manuel D.

Hi folks,
I need help finding out how to fix a Continuity counter error when tuning IPTV, see an extract of the log and config files below.
I am using at this moment HTS Tvheadend 3.9.689~g236ebc9~trusty (latest unstable from Ubuntu repository for Ubuntu 14.04 Trusty). This error was always there with any previous version of Tvheadend and under Ubuntu 13.04 and 13.10 as well.
I can watch these channels, and the problem are visible artefacts in form of pixelated presentation of a small part of the picture at the bottom of the screen when watching IPTV channels. I have also DVB-T, DVB-S and DVB-S2 channels and they are ok. The problem only happens with IPTV channels and this is the only error visible in the logs.
Thank you very much in advance for helping with this problem.
Manuel D.
Log example:

2014-05-23 16:51:13.204 mpegts: udp://@239.0.5.87:8208 - tuning on IPTV 2014-05-23 16:51:13.204 subscription: "HTTP" subscribing on "TNT HD (IP)", weight: 100, adapter: "IPTV", network: "IPTV Movistar", mux: "udp://@239.0.5.87:8208", provider: "", service: "TNT HD (IP)" 2014-05-23 16:51:13.357 TS: udp://@239.0.5.87:8208/TNT HD (IP): H264 @ #101: Continuity counter error 2014-05-23 16:51:14.020 TS: udp://@239.0.5.87:8208/TNT HD (IP): H264 @ #101: Continuity counter error, 10 duplicate log lines suppressed 2014-05-23 16:51:15.040 TS: udp://@239.0.5.87:8208/TNT HD (IP): H264 @ #101: Continuity counter error, 25 duplicate log lines suppressed 2014-05-23 16:51:16.010 TS: udp://@239.0.5.87:8208/TNT HD (IP): H264 @ #101: Continuity counter error, 46 duplicate log lines suppressed 2014-05-23 16:51:17.043 TS: udp://@239.0.5.87:8208/TNT HD (IP): H264 @ #101: Continuity counter error, 60 duplicate log lines suppressed 2014-05-23 16:51:18.198 TS: udp://@239.0.5.87:8208/TNT HD (IP): H264 @ #101: Continuity counter error, 77 duplicate log lines suppressed 2014-05-23 16:51:19.086 TS: udp://@239.0.5.87:8208/TNT HD (IP): H264 @ #101: Continuity counter error, 94 duplicate log lines suppressed 2014-05-23 16:51:20.058 TS: udp://@239.0.5.87:8208/TNT HD (IP): H264 @ #101: Continuity counter error, 112 duplicate log lines suppressed 2014-05-23 16:51:21.065 TS: udp://@239.0.5.87:8208/TNT HD (IP): H264 @ #101: Continuity counter error, 125 duplicate log lines suppressed 2014-05-23 16:51:21.987 mkv: Live stream: Write failed -- Broken pipe 2014-05-23 16:51:21.987 webui: Stop streaming /stream/channel/74e1c503f0f6a1e2d7ed8d2ea1fc8390, muxer reported errors 2014-05-23 16:51:21.987 subscription: "HTTP" unsubscribing from "TNT HD (IP)"

Corresponding Mux and config:

{ "sid": 601, "lcn": 0, "svcname": "TNT HD (IP)", "dvb_servicetype": 0, "prefcapid": 0, "enabled": true, "pcr": 101, "pmt": 100, "stream": [ { "pid": 101, "type": "H264", "position": 0, "width": 1920, "height": 1080, "duration": 3600 }, { "pid": 201, "type": "MPEG2AUDIO", "position": 0, "language": "und", "audio_type": 1 }, { "pid": 202, "type": "MPEG2AUDIO", "position": 0, "language": "vol", "audio_type": 1 }, { "pid": 401, "type": "DVBSUB", "position": 0, "language": "und", "compositionid": 1, "ancillartyid": 0 } ] }

{ "iptv_url": "udp://@239.0.5.87:8208", "iptv_interface": "p72p1", "iptv_atsc": false, "iptv_svcname": "TNT HD (IP)", "enabled": true, "onid": 65535, "tsid": 1, "initscan": true }

Corresponding network setting:

{ "max_streams": 0, "max_bandwidth": 0, "networkname": "IPTV Movistar", "nid": 0, "autodiscovery": true, "skipinitscan": true }

Corresponding channel config:


{
        "name": "TNT HD (IP)",
        "number": 51,
        "dvr_pre_time": 0,
        "dvr_pst_time": 0,
        "services": [
                "bea17e542824cf86e371d859ef296bde"
        ],
        "tags": [
                5,
                1,
                2
        ]
}

Phill Lavender

Manuel,
The continuity errors on Movistar (Imagenio) are likely the bandwidth you have available for the channel either your LAN or WAN.
Question. If you record a channel for a few seconds does it still give you the pixelation issues ? (Open the recorded file locally from VLC and let me know)
How is your local network configured. Wired gigabit ? Any switches in-between the tvheadend machine and the router ?
Is 'p72p1' a virtual interface or a physical one ?
I'll help where I can, it's been a few years since I lived in Spain and had Imagenio but I did get it working very well.
Phill

Manuel D.

thanks phill,
this interface is physical, a gigabit interface, wired, it is connected directly to the router, which is a gigabit router, no switch in-between!
vlc has no such problem at all, and for that matter no other app i have tested does, nor does vdr, which i have tested as well!
the wan connection is 100 megabit fibre optic!
as for the test you asked, when i record it with tvheadend and then watch it with vlc, then same pixelation issues are there!

hope this take us further, thanks again for your help!

Phill Lavender

Noticed something. Not sure who maintains the unstable Ubuntu repository for 14.04, but I've had build issues with some of the lastest gits. Build #4837 - v3.9.570 was the last one the bot was able to build. I'd revert to that and use the file from the builds section to install it.

Have you tried using the transcoding (it'll use libav) and a different container?

Really there's nothing obvious that sticks out. You could take a 10sec wireshark dump of one of the streams and post it to a bug report. It would give the devs something concrete to look at.

Phill

Phill Lavender

You could also have a look here:

https://tvheadend.org/issues/1986

I'm not sure if the code for iptv allows 'PMT monitoring' but you could defiantly try to check it's off.

Looks like there are some know issues though that adam is aware of.

Adam's point in the thread is spot on:-

-------------

Updated by Adam Sutton about 1 month ago

Comment

The problem is that there are CC errors in the stream, a CC error in simple terms means "something went missing". Basically each packet carries a 4 bit counter (unique to the PID), if you get a packet with a CC which is not exactly +1 from the last, then you've missed something and got a continuity error.

Now this can happen for several reasons, but the most common are:

1. Intentional errors. This is rare, but not unheard of for some DVB broadcasters to insert intentional errors to try and trip up unofficial receivers (though it should at worst cause unnecessary error reports, not real damage).

2. Lost in transit, due to errors etc... (i.e. receiver hardware never received the packet)

3. Lost in transfer, i.e. packet arrived, but was lost from buffers before it was passed to application (usually implies application running slowly, and my original thoughts on this issue).

4. Lost in processing, it got to the application but then mysteriously disappeared (i.e. a bug in the processing logic).

I'm ignoring 1 assuming its a non-issue. 1 is difficult to disprove, however your dump file which was generated with a completely different application shows CC errors (so I can only surmise that some genuine, transit, errors are occurring, though odd no transport errors are reported).

3 is really difficult to test without real systems on which the problems occur, however I've done quite a bit to improve this so I really hope this is gone. But you could check very latest master and look at the new CC counter field on the stream status page.

4 is probably the most likely source of errors. At the moment I'm not sure packets are going missing as such, but possibly the way in which CC errors are treated is less than ideal.

Adam

-------

Post your Debug logs.

Phill

Manuel D.

thanks again phill,
i have tested this build in the past Build #4837 - v3.9.570, and i remember that i had to revert back to it from later bad builds. but it was all the same with iptv. i am dealing with this problem for quite some time now, longer than a month.
i also tried a transcoding build 3 weeks ago, actually not related to this bug, but in connection to a plex plugin that uses transcoding, it worked fine, but the iptv error was still there. it has been there all this time, no matter what i have tried. like for example compiling other libraries that tvheadend relies on, but the results were all the same.
i also do not know who is responsible for these ubuntu builds, but except for this bug, everything else seems to be working as expected.
here i am attaching a current debug log (started like this tvheadend -f -u hts -g video -s), hope this helps, thanks!
and a wireshark dump.

Manuel D.

i just compiled manually latest version 3.9.722~g65a3c45, all went perfect with the compilation, but the error with iptv is still there, although i get the impression that it gets better with latest builds, but i cannot be sure because the cc errors are still there, but the picture seems to be less affected.

when the picture takes the full screen it is not ok, but the problem is visible only in the last lines of the picture, so it is mostly acceptable, the problem gets bad when the picture takes only part of the screen and the screens shows black bars, here the error also happens in the the last lines, but then as a side effect it expands over the bottom black bar and it becomes annoying, it produces sometimes a sort of reflection of the picture in the black bar, which makes this effect worst, as it sort of distorts the whole picture.

Phill Lavender

I think this is may be issue based on the log.

May 26 14:12:13 Nest tvheadend[1065]:cat: invalid table length 5 min 7

May 26 14:12:13 Nest tvheadend[1065]: message repeated 6 times: [ cat: invalid table length 5 min 7]

Phill

Manuel D.

thanks phill, yes, this is the only message visible, but now what is it and how do i fix this?

Manuel D.

it appears here https://github.com/tvheadend/tvheadend/blob/master/src/input/mpegts/dvb_psi.c (google does not show it elsewhere :-( ), but this finding is not helping me much...

Phill Lavender

When Tvheadend parses the DVB tables it complaining because the length of the CAT table isn't as it expects.

Does Movistar encrypt the iptv feed now ? Do you need a CI and Card to view it ?

Movistar never used to encrypt the stream, so I suspect that something else in the stream is making tvheadend bump the positions on the stream and decode the tables incorrectly. Either Movistar injected something into the stream or the parser isn't quite accurate. (work to investigate either way !)

Can you run a dvbsnoop and dump a cat table pid 0x01, I think you should be able pipe ncat to dvbsnoop.

Phill

Manuel D.

gonna do that asap, as for your question, no movistar is not encrypting it, no CI in play here.
i gonna suppose something is being injected and tvheadend is reacting accordingly to it, but vlc and vdr for example do not care and the picture in this other apps is ok, i hope tvheadend can be recoded to do the same...

Phill Lavender

You can try this also:

mplayer rtp://ip:port -dumpstream -dumpfile stream.ts

dvbsnoop -s ts -if stream.ts > snoop.txt

Phill

Phill Lavender

BTW. Did you ever try tvheadend 2.13 that was the version I was using when I was in Madrid. I didn't have fibre, but it worked fine over 20mb adsl for std def channels. I think v3 was the beginning of Adam's major rewrite, so it would be good test to see if the issue was there back then.
Phill

Manuel D.

no, never tried this old version, it crossed my mind actually, but everything else works as expected, and i am looking for a long term solution, this older version is or will be deprecated, so i never did...

here it goes, the snoop file as you suggested in the previous post using mplayer (this is fox hd channel rtp://@239.0.9.134:8208)

(oops, too big, gonna hit ctrl-c sooner in my next try)

Manuel D.

and here it goes, these are rather big text files that dvbsnoop produces...

Phill Lavender

I've raised a defect report for the cat: Invalid Length with a suggested fix (reduce the minlength from 7 to 5). Looking at the code though it's unlikely the cause of the other continuity issues.

Did you try 2.13 ? I just want to now if something was introduced in the rewrite that could cause this.

Thx

Phill

Phill Lavender

I've been looking at this a little more this evening and reading up on udp size etc, I don't claim to be an expert but here's what I noticed. The old 2.13 code use to set the setsockopt SO_RCVBUF to 262142 bytes, for the udp receive buffer, which was basically the default linux OS default . You can check you system setting using:

/proc/sys/net/core/rmem_default

/proc/sys/net/core/rmem_max

The current code use 300*188 as the setsockopt SO_RCVBUF which is much smaller.

Now honestly I have no clue if this makes a difference, but if your amenable to compiling your own code, you could try adjusting the receive buffer and see if that makes a difference with the dropped packets.

You'll need to change iptv_udp.c IPTV_PKT_SIZE below and replace it with 262142

conn = udp_bind("iptv", name, url->host, url->port,

im->mm_iptv_interface, IPTV_PKT_SIZE);

Phill

Manuel D.

thanks phill,
i am sorry, i did not try 2.13, to my knowledge this version is very different, so i did not try, i also expect that this will take me several hours and i am waiting for the right moment to do so.
i have recompiled as you suggested changing IPTV_PKT_SIZE but all remained the same, this change did not make any visible impact, the error was the same, no new error, no less errors, and the picture presented the same problem, no more, no less.
i have no idea how to play with this number, so i reverted it..

Phill Lavender

Can you run a full trace and post the log. I'm not sure what all the trace options are but something like this should be sufficient.

--trace mpegts,linuxdvb,iptv,udp,psi,pmt,cat -l tvh.log

Hopefully that works and give a full breakdown of code

Thanks

Phill