Tvheadend

In my experience the absolutely only cause of continuity counter errors is bad hardware, bad cabling, or both.

If so, how can you explain, that in VDR (http://www.tvdr.de/) it works without any problem?

Is there any debug output I can provide for examination?

Jalle Grönroos wrote:

In my experience the absolutely only cause of continuity counter errors is bad hardware, bad cabling, or both.

He is not only one with this error i also have same problem see: https://tvheadend.org/issues/1977

Also and other: https://tvheadend.org/boards/5/topics/11179 , https://tvheadend.org/boards/5/topics/11053

I did some additional testing and found out that it affects all channels from the same transponder. I also found out that if I start streaming in certain moment, it plays without any error and when I stop it and start it again it shows errors again. I think there is some bug in demuxing function.

All,

I have discovered a couple of issues that need to be looked at, I will post some fixes soon. Though not sure I've uncovered all possible causes.

Adam

Adam Sutton wrote:

All,

I have discovered a couple of issues that need to be looked at, I will post some fixes soon. Though not sure I've uncovered all possible causes.

Adam

Hi Adam,

Thanks for your hard work. Do you can see also my problem same error, this thread https://tvheadend.org/issues/1977
I test on new PC with new dish, cable, other convertor still the same. See my thread.
I can give access to a system where this error.

Regards

All my HD channels gets errors, and flickering/objects/stuttering:
Apr 14 21:40:23.466 TS: Sundtek DVB-C (III)/Get.: 386,000 kHz/TV2 HD: H264 @ #1634: Continuity counter error, 44 duplicate log lines suppressed

- And it just goes on and on, counting errors.

Hope there's a fix to this because I absolutely love Tvheadend.
(Have a batch off two more Sundtek's arriving to test if that tuner alone isn't the problem, otherwise cabling is fine.)

"I really need access to a system where this is happening (I do have offers already) and some time to investigate further."

My system is a Synology DS1812+, that is completely at your disposal if needed.

I also thank you for your hard work, keep it up

Please try master, again.

Adam

All I've found is this package from synocommunity.
https://github.com/SynoCommunity/spksrc/commits/develop/spk/tvheadend

Tvheadend 3.4.27

I'm a little worried about how to install without a "package".

Do you mean I should un-install that package and build tvheadend on my synology like this?
https://tvheadend.org/projects/tvheadend/wiki/Building
I think the synology has git bootstrapped, but im new to linux.

Adam Sutton wrote:

Please try master, again.

Adam

I try master from github, now many bad, anything don't work. Free , encrypted any channel don't work give many error.

When start give:

2014-04-15 03:40:02.287 [WARNING] psi: PID 0012 CC error 9 != 8

2014-04-15 03:40:02.287 [WARNING] psi: PID 0012 CC error 9 != 8
2014-04-15 03:40:02.287 [WARNING] psi: PID 0012 CC error 9 != 8
2014-04-15 03:40:02.287 [WARNING] psi: PID 0012 CC error 9 != 8
2014-04-15 03:40:02.287 [WARNING] psi: PID 0012 CC error 9 != 8
2014-04-15 03:40:02.287 [WARNING] psi: PID 0012 CC error 9 != 8
2014-04-15 03:40:02.287 [WARNING] psi: PID 0012 CC error 9 != 8
2014-04-15 03:40:02.287 [WARNING] psi: PID 0012 CC error 9 != 8
2014-04-15 03:40:02.287 [WARNING] psi: PID 0012 CC error 9 != 8
2014-04-15 03:40:02.288 [WARNING] psi: PID 0012 CC error 9 != 8
2014-04-15 03:40:02.288 [WARNING] psi: PID 0012 CC error 9 != 8
2014-04-15 03:40:02.288 [WARNING] psi: PID 0012 CC error 9 != 8
2014-04-15 03:40:02.288 [WARNING] psi: PID 0012 CC error 9 != 8
2014-04-15 03:40:02.447 [WARNING] linuxdvb: TurboSight TBS 6981 DVBS/S2 frontend : DVB-S #0 - read() EOVERFLOW
2014-04-15 03:40:03.003 [WARNING] TS: 12092H/Mooz Dance HD: MPEG2AUDIO #5201: Continuity counter error, 39884 duplicate log lines suppressed
2014-04-15 03:40:03.003 [WARNING] TS: 12092H/Mooz Dance HD: H264 #5101: Continuity counter error, 39884 duplicate log lines suppressed
2014-04-15 03:40:04.003 [WARNING] TS: 12092H/Mooz Dance HD: MPEG2AUDIO #5201: Continuity counter error, 47958 duplicate log lines suppressed
2014-04-15 03:40:04.003 [WARNING] TS: 12092H/Mooz Dance HD: H264 #5101: Continuity counter error, 47958 duplicate log lines suppressed
2014-04-15 03:40:04.032 [WARNING] webui: Couldn't start streaming /stream/service/1aa06676a7520e6311b188a217aeec37, No input detected

Give this on every channels!

I'm sorry, I just realized I might've tried to hijack this thread :/ I did find another package though, will start another thread regarding this and synology.

Hi, I tested it with current version from git but nothing changed. When I start TVH, and start channel A I'm getting:

2014-04-17 07:39:59.280 [WARNING] psi: PID 03E7 CC error 7 != 8
2014-04-17 07:39:59.336 [WARNING] psi: PID 0012 CC error 12 != 13
2014-04-17 07:39:59.336 [WARNING] psi: PID 0012 CC error 1 != 2
2014-04-17 07:39:59.350 [WARNING] psi: PID 0012 CC error 4 != 5
2014-04-17 07:39:59.350 [WARNING] psi: PID 0309 CC error 8 != 9
2014-04-17 07:39:59.350 [WARNING] psi: PID 0012 CC error 7 != 8
2014-04-17 07:39:59.350 [WARNING] psi: PID 0012 CC error 10 != 11

then I switch to channel B which doesn't have this problem anytime and switch back to A and it plays with no problem. Is it possible that this be somehow related to CSA?

Update: I don't need to change to another channel to stop those messages, its enough to stop and start the same problematic channel.

• restart tvheadend
  - 2 adapters enabled

• 1 adapter is initscanning
• 1 adapter tuned and continuity errors abound
  Apr 18 18:41:03 sat tvheadend³²⁹⁶: psi: PID 00B6 CC error 11 != 7
  Apr 18 18:41:03 tvheadend³²⁹⁶: last message repeated 3 times
  Apr 18 18:41:03 sat tvheadend³²⁹⁶: psi: PID 00B6 CC error 8 != 12
  Apr 18 18:41:03 tvheadend³²⁹⁶: last message repeated 3 times
  Apr 18 18:41:03 sat tvheadend³²⁹⁶: psi: PID 0012 CC error 0 != 3
  Apr 18 18:41:03 sat tvheadend³²⁹⁶: pmt: invalid checksum
  Apr 18 18:41:03 sat tvheadend³²⁹⁶: psi: PID 0012 CC error 4 != 0
  Apr 18 18:41:03 sat rsyslogd-2177: imuxsock begins to drop messages from pid 3296 due to rate-limiting
  Apr 18 18:41:07 sat rsyslogd-2177: imuxsock lost 285 messages from pid 3296 due to rate-limiting
  Apr 18 18:41:07 sat tvheadend³²⁹⁶: TS: 12187H/Veronica/DisneyXD HD: H264 @ #517: Continuity counter error, 2932 duplicate log lines suppressed

But... if I have the transmission active and I go to Configure - Mux and try to save the mux stream, it goes to the 2nd adapter and incurs no CC errors. The adapter that is streaming the transmission keeps incurring CC errors.

Please tell me how to diagnose this more.

hello,

i'm on Build: 3.9.542~g63ac3be and did not get any continuity error anymore (i have 8 digital devices s2) and got this error everytime more than one tuner was active - but now i'm running all 8 and did not see any so far - cool my freezers are gone...

thanks a lot

holli

I added mesh shielding around my sat cards and can now confirm that reception is fine with 3.9.542. It would seem the motherboard or (more likely) the graphics card sprayed noise into the receiver.
So reception on one adapter is no longer impacted by another adapter doing init scan.
This applies for FTA and encrypted channels (using oscam mode 2 and genuine smartcards in Omnikey readers).
Thank you, Adam!

Live streaming of channels works well, as I stated yesterday.
I still see a large number of CC errors within eit messages. I've saved a mux stream: https://www.dropbox.com/s/sxgpuoimq4vwk91/10802H.ts

Apr 21 07:45:54 sat tvheadend⁹⁵²: mpegts: 10802H - starting for 'epggrab' (weight 1)
Apr 21 07:45:54 sat tvheadend⁹⁵²: mpegts: 10802H - tuning on STV090x Multistandard : DVB-S #0
Apr 21 07:45:55 sat tvheadend⁹⁵²: subscription: 'epggrab' subscribing to mux, weight: 1, adapter: 'STV090x Multistandard : DV
B-S #0', network: '19.2E', mux: '10802H'
Apr 21 07:46:00 sat tvheadend⁹⁵²: eit: invalid checksum
Apr 21 07:46:10 tvheadend⁹⁵²: last message repeated 4 times
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0000 CC error 13 != 5
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0000 CC error 6 != 13
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 15 != 0
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 3 != 4
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 9 != 10
Apr 21 07:46:10 sat tvheadend⁹⁵²: eit: invalid checksum
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 3 != 4
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 13 != 14
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 0 != 1
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0000 CC error 15 != 7
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0000 CC error 8 != 15
Apr 21 07:46:10 sat tvheadend⁹⁵²: pat: invalid checksum
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0011 CC error 12 != 11
Apr 21 07:46:10 sat tvheadend⁹⁵²: bat: invalid checksum
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0011 CC error 12 != 11
Apr 21 07:46:10 sat tvheadend⁹⁵²: sdt: invalid checksum
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 15 != 0
Apr 21 07:46:10 sat tvheadend⁹⁵²: eit: invalid checksum
Apr 21 07:46:10 sat tvheadend⁹⁵²: eit: invalid checksum
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 2 != 0
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 1 != 3
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 4 != 5
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 6 != 7
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0001 CC error 11 != 7
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0001 CC error 8 != 12
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 13 != 14
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 1 != 3
Apr 21 07:46:10 sat tvheadend⁹⁵²: eit: invalid checksum
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0010 CC error 13 != 7
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 7 != 8
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 15 != 13
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 14 != 1
Apr 21 07:46:10 sat tvheadend⁹⁵²: eit: invalid checksum
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0000 CC error 0 != 1
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 7 != 8
Apr 21 07:46:10 sat tvheadend⁹⁵²: eit: invalid checksum
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 10 != 11
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 13 != 14
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 15 != 0
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 6 != 14
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 15 != 8
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 15 != 0
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 10 != 11
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 11 != 12
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 0 != 8
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0012 CC error 9 != 1
Apr 21 07:46:10 sat tvheadend⁹⁵²: eit: invalid checksum
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0010 CC error 8 != 13
Apr 21 07:46:10 sat tvheadend⁹⁵²: eit: invalid checksum
Apr 21 07:46:10 sat tvheadend⁹⁵²: psi: PID 0983 CC error 0 != 1
Apr 21 07:46:10 sat tvheadend⁹⁵²: eit: invalid checksum
Apr 21 07:46:10 tvheadend⁹⁵²: last message repeated 2 times
Apr 21 07:46:10 sat tvheadend⁹⁵²: pmt: invalid checksum
Apr 21 07:46:10 sat tvheadend⁹⁵²: subscription: "epggrab" unsubscribing
Apr 21 07:47:21 tvheadend⁹⁵²: last message repeated 4 times

and the occasional blip while viewing

Apr 21 07:48:00 sat tvheadend⁹⁵²: TS: 11739V/FOX Channel: H264 #516: Continuity counter error
Apr 21 07:48:00 sat tvheadend[952]: TS: 11739V/FOX Channel: MPEG2AUDIO #88: Continuity counter error
Apr 21 07:48:12 sat tvheadend⁹⁵²: psi: PID 0010 CC error 15 != 4
Apr 21 07:48:12 sat tvheadend⁹⁵²: TS: 11739V/FOX Channel: H264 @ #516: Continuity counter error
Apr 21 07:48:12 sat tvheadend⁹⁵²: psi: PID 0010 CC error 5 != 15

Ron / Dan,

How did you capture those muxdumps? I think you will need to use something other than TVH or at the very least an older version (since unfortunately those raw dumps aren't so raw these days, they could well already be infected with the issue we're trying to investigate).

Adam

I used dvbsnoop:
dvbsnoop -s ts -tsraw -b -n 0 > dump.ts

Daniel,

How was the device tuned? Another external app presumably? I.e. TVH was in no way involved in the process of generating that file?

Because looking at that TS file it is indeed filled with CC errors, so TVH would be correct in reporting them.

Adam

I've used THV for transponder tunning. Now I've made another dump with VDR as tuner (dumping using dvbsnoop) with the same channel on same card playing perfectly.

http://danman.eu/dump2.ts

Ok, that's definitely cleaner, though its still got errors in it, so I'd expect some reporting from TVH.

That being said I think my handling of those errors may be causing more problems than it should.

Adam

I still don't understand why it is working perfectly in VDR and in TVH not. Could you at least simply describe what's the point of the problem please?
Thank you.

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

I've foud it!!!!

My card is not able to handle so many PIDs as TVH request so it starts dropping packets. To check if this was the reason, I tried this patch:

diff --git a/src/input/mpegts/dvb_psi.c b/src/input/mpegts/dvb_psi.c
index f4ce6b1..c42a267 100644
--- a/src/input/mpegts/dvb_psi.c
++ b/src/input/mpegts/dvb_psi.c
@ -575,7 +575,8 @ dvb_pat_callback
/* Process each programme */
ptr += 5;
len = 5;
while(len >= 4) {
// danmnan while(len >= 4) {
+ while(0) {
sid = ptr⁰ << 8 | ptr¹;
pid = (ptr² & 0x1f) << 8 | ptr³;

After this, I was able to watch without a single drop! I hope you will find some more systematic way how to fix it in next releases :).
Good night.

diff --git a/src/input/mpegts/dvb_psi.c b/src/input/mpegts/dvb_psi.c
index f4ce6b1..c42a267 100644
--- a/src/input/mpegts/dvb_psi.c
+++ b/src/input/mpegts/dvb_psi.c
@@ -575,7 +575,8 @@ dvb_pat_callback
   /* Process each programme */
   ptr += 5;
   len -= 5;
-  while(len >= 4) {
+// danmnan while(len >= 4) {
+  while(0) {
     sid = ptr[0]         << 8 | ptr[1];
     pid = (ptr[2] & 0x1f) << 8 | ptr[3];

I've just made a point that I'm really not going to spend lots of time trying to support such hardware unfortunately. But I will have a think...

Adam

I think that your approach is wrong. Why do you waste resources for permanent transponder scanning while the user only requested to watch single channel which PIDs we allready know? Shouldn't be this (scanning) done only once a time to update table with available programs?

The reality is that for most tuners it's not a problem and its hardly a big waste of resource, open PID, scan for few seconds processing and then ignore stuff. Compared to everything else going on its trivial. However I'll have a think, I had a simple fix, but that really won't do the job.

Adam

Dan,

can you try this, http://sprunge.us/TiQS, I've done VERY limited testing, but woud welcome some input.

Adam

Hi Adam,

it works fine. Thank you.

Adam Sutton wrote:

Applied in changeset commit:tvheadend|c361cc6c692114f7bf4f0274aa4bb289141b4e5a.

I'm currently using build 4.0.4 + 4 DVBSky S960 tuners and having similar problems, but I can't find the "Disable PMT monitoring" option...

Thanks

Cassio

The current code uses different mechanism - it opens PMT PIDs only during the scan and it limits the number of open PIDs according the user config (in the hardware tree tab).