[hegg]

Hi,

when I've enabled Over-The-Air EPG (within the DVB input setup), I receive consecutively the folliowing error:

Code:

Apr  3 13:51:32 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: H264 @ #1023 Continuity counter error (total 21)
Apr  3 13:51:32 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: AC3 @ #1027 Continuity counter error (total 15)

This error makes a picture and sound interrupt.
Here's an example how often the error occurs:

Code:

root@kodi:~# grep "Continuity counter error" /var/log/syslog
Apr  3 13:46:45 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: H264 @ #1023 Continuity counter error (total 1)
Apr  3 13:47:06 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: H264 @ #1023 Continuity counter error (total 4)
Apr  3 13:47:06 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: AC3 @ #1027 Continuity counter error (total 1)
Apr  3 13:47:06 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: TELETEXT @ #32 Continuity counter error (total 1)
Apr  3 13:47:48 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: AC3 @ #1027 Continuity counter error (total 3)
Apr  3 13:47:48 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: TELETEXT @ #32 Continuity counter error (total 4)
Apr  3 13:47:51 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: H264 @ #1023 Continuity counter error (total 7)
Apr  3 13:48:16 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: H264 @ #1023 Continuity counter error (total 9)
Apr  3 13:48:16 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: AC3 @ #1027 Continuity counter error (total 6)
Apr  3 13:48:17 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: TELETEXT @ #32 Continuity counter error (total 7)
Apr  3 13:49:19 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: H264 @ #1023 Continuity counter error (total 12)
Apr  3 13:49:26 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: AC3 @ #1027 Continuity counter error (total 9)
Apr  3 13:50:15 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: H264 @ #1023 Continuity counter error (total 18)
Apr  3 13:50:15 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: AC3 @ #1027 Continuity counter error (total 12)
Apr  3 13:50:16 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: TELETEXT @ #32 Continuity counter error (total 10)
Apr  3 13:51:32 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: H264 @ #1023 Continuity counter error (total 21)
Apr  3 13:51:32 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: AC3 @ #1027 Continuity counter error (total 15)
Apr  3 13:51:32 kodi tvheadend[1976]: TS: Astra/11914.5H/Discovery HD: TELETEXT @ #32 Continuity counter error (total 198)
Apr  3 13:53:40 kodi tvheadend[1976]: TS: Astra/12574.25H/DMAX HD: H264 @ #767 Continuity counter error (total 1)
Apr  3 13:53:40 kodi tvheadend[1976]: TS: Astra/12574.25H/DMAX HD: TELETEXT @ #34 Continuity counter error (total 1)
Apr  3 13:53:40 kodi tvheadend[1976]: TS: Astra/12574.25H/DMAX HD: AC3 @ #771 Continuity counter error (total 1)

Code:

root@kodi:~# tvheadend --version
tvheadend: version 4.1-1491~g6c3d114

When I disable the over-the-air EPG, the error did not disappear, but it's really rare then. Additionally I've disabled "Force EPG on startup", which makes obviously no difference.
Does anyone of you might have an idea, how to use the over-the-air EPG without these problem?

I would really appreciate any kind of help/or ideas.
Thanks in advance.

[abga]

@hegg - if you're still active

I'm experiencing exactly the same issue now after upgrading my Pi's kernel to 4.9.28-v7+ and recompiling media_build (media tree) from git. I need to recompile it because I have a weird DVB-S2 tuner that has a rejected patch that makes it work flawlessly.
I can confirm that this is NOT a tvheadend issue, as I restored the backup (whole SD Card) from my previous Pi image with the same tvheadend version & config and I have absolutely no issues now. The guys at linuxtv.org (media_tree) - hard to get BTW - are apparently happy breaking things that work. I'll stick with my older kernel and stuff - compiled in March 2017.

Your hint - disabling the Over-The-Air EPG helps in that I got a Continuity counter error every 5 minutes after applying it, before I had one every 1 minute.
However, after a while (1-2 hours) this error will pop in syslog and goodbye watching TV (tvheadend needs to be restarted - DVB Tuner reinitialized):
tvheadend[16866]: pass-eit: invalid checksum (len 987, errors 1)

media_build git version (last commit) that worked fine (compiled March 2017):
https://git.linuxtv.org/media_build.git/...9b4df9783e

actual media_build version (last commit) that is messed up (compiled July 2017):
https://git.linuxtv.org/media_build.git/...2111b77587

[abga]

I've excluded media_tree for the moment, as I compiled the new build under an older kernel / firmware (Raspberry Pi) and tvheadend was happy.
Furthermore, under the new firmware & kernel, by setting the CPU clock governor on performance instead of ondemand, thus keeping the CPU at its maximum clock all the time, the tvheadend continuity issues disappeared.

Stumbled upon an older thread describing a throttling issue (x86 CPUs) and investigating it ATM:

https://tvheadend.org/boards/5/topics/8502?r=8790

[rpcameron]

Continuity errors are essentially processing errors. They mean that packets are being decoded/assembled out of order, or that they are being dropped. This is usually the case when your hardware does not have the bandwidth/power to keep up with the stream coming in.

If you are using a network tuner (such as HDHomeRun), ensuring you are using the HDHomeRun client in Tvheadend will help (as opposed to using HTTP/IPTV streams) makes a big difference.

If your tuner is USB, make sure you have the bandwidth to handle it, especially if you are using multiple USB devices. This is most important on limited devices such as the Raspberry Pi.

The Pi is a great little board for small uses, but a bandwidth powerhouse it most certainly is not. (I find they make great clients for Kodi, but TV servers not so much.)

[abga]

@rpcameron

Thank you very much for your hints and explanations! I'm using tvheadend and Kodi (omxplayer) on the same Pi2B as a "smart TV" system and I really like it, CPU usage under full HD will not get over 20%-30% and the CPU is staying cool at 600Mhz - 56C.
My issue is simpler than you'd suspected, I just upgraded the firmware & kernel from the official Raspbian image and started to experience these issues. That's on the same box, cables, and Linux distribution (Slackware) - including conf files and packages.
I'm going through this process every month (actually, once a new Raspbian image is released) for the last 1-2 years and never had any issues until now.

Today I got some time and took a look on the commits history of the firmware and found out that there were no (documented) changes that could have caused the issues I'm experiencing now.
It's only the new kernel that was left for investigation and I'm suspecting that there are some timing / synchronization issues in the usb subsystem. But those are hard to investigate and, as you said, the Pi has bandwidth issues mainly on the usb bus where everything is connected.
I'm happy now with the previously released kernel and considering to use a Pi Zero, embed it in the tuner, and forget it there until the tuner dies

[jahutchi]

I'm a LibreELEC user, and had the exact same problem with the LibreELEC 8.0.x production builds.

It turned out to be that a problem was introduced in the core linux kernel for USB DVB devices and there is a long thread on this here:
https://forum.libreelec.tv/thread/4235-d...nel-4-9-x/

I'm on a reasonably powerful Generic x86 HTPC ... 4x 1.8GHz processor cores, 4GB RAM, ION2 GPU. Generally when watching a TV Show my CPU is around 20% used, and I only get the continuity errors and picture break-ups in distributions that ship with a v4.9 or above kernel. At the moment I am using a LibreELEC community build with 4.8.13 kernel as provided in the thread above (have been for the past few months) and the continuity errors have gone so everything is sweet.

I really hope this gets fixed upstream so I can eventually upgrade my kernel. Reading the thread above it looks like they've identified the set of kernel commits where the problem was introduced, but are struggling to track down the individual commit.

My advice to you would be to downgrade your kernel to something less than v4.9.

[abga]

@ jahutchi

Thank you for confirming this issue with the kernels starting from 4.8/4.9. and also for the link you provided.
Meanwhile I raised the issue with the folks at Raspberry and got mobbed out from their Forum

However, I documented my findings on LinuxQuestions:
https://www.linuxquestions.org/questions...ost5733274
- there are USB related issues that even the folks at Raspberry have observed with the new 4.9 branch - check the links form my LQ posts
- I'm still using the 4.4.50 kernel, never truly upgraded but only tried it and got the issues I've reported
- therefore I'd like to confirm your advice, stick with kernels beyond 4.8/4.9 for the moment

[jahutchi]

Just an update on this old thread.

I myself managed to track down the troublesome commit by bisecting the 4.9.x kernel:

See here:
https://forum.libreelec.tv/thread/42...5965#post75965

And the troublesome commit turned out to be this one:
https://git.kernel.org/pub/scm/linux...500098f2d5f882

Later in the thread (page 15) you will see that the kernel folks (incl the media subsystem maintainer) are now involved, and there are some interesting threads on the kernel discussion board - looks like this is still work in progress as nothing has yet been committed to the upstream kernel to resolve this, but hopefully a permanent fix is in the linux kernel pipeline.

So unless your kernel has the same revert patch committed by the LibreELEC devs:
https://github.com/LibreELEC/LibreELEC.t...-job.patch

Then you probably still need to stick with an older kernel for now, or figure out how to patch and recompile the kernel for your O/S.

[abga]

[abga]

Just found out that the folks at Raspberry Foundation reverted the offending commit in their latest kernel release that comes with Raspian:
https://www.raspberrypi.org/downloads/raspbian/
Version: March 2018
Release date: 2018-03-13
Kernel version: 4.9

The exact kernel version after opening the Raspbian image (Kinder Surprise) is 4.9.80+ and the source code for this kernel build is to be found at (152MB !):
https://github.com/raspberrypi/linux/arc...130.tar.gz

Running a diff on the files: /kernel/softirq.c (from the source archive) and the reference from Linus' master at:
https://github.com/torvalds/linux/blob/m.../softirq.c
got me exactly the offending commit:
https://git.kernel.org/pub/scm/linux/ker...98f2d5f882

I haven't tested this kernel yet but will do so in the following days. As the commit was simply reverted and no patch applied, I don't expect to get into any issues with this new kernel and hope to enjoy the same stability as with my actual 4.4.50+

It's interesting to follow the development on the softirq.c with the kernel folks (pretty difficult as it is spread over a few threads) and hope they'll come up with a resolution soon that will be generally available and backported/updated.

[zzlateff]

Code:

2018-03-26 14:33:31.717 TS: MyDVB-C/722MHz/Nick Jr: MPEG2VIDEO @ [url=http://www.wetekforums.com/v/search?Search=%2345&Mode=like]#45[/url] Continuity counter error (total 1)

 

This is the error I get when I stream from DVB-C. The stream is working (with 3-4K bitrate) but Kodi (PVR client) does not show picture. The weird thing is some channels work fine and others have no picture. On every channel that does not work the following error comes up:

Code:

2018-03-26 14:33:31.717 TS: MyDVB-C/722MHz/Nick Jr: MPEG2VIDEO @ [url=http://www.wetekforums.com/v/search?Search=%2345&Mode=like]#45[/url] Continuity counter error (total 1)

 
Or 

Code:

2018-03-26 14:33:31.717 TS: MyDVB-C/722MHz/Nick Jr: H264 @ #531  Continuity counter error (total 1)

 
Or

Code:

2018-03-26 14:33:31.717 TS: MyDVB-C/722MHz/Nick Jr: MPEG2AUDIO@ #531  Continuity counter error (total 1)

 

Apart from DVB-C as source of channels I also have a DVB-S playlist from Wetek 1 S2 tunner. Some channels from this playlist also have this error and there's no picture. 


HTS Tvheadend 4.2.3-20 ~ LibreELEC Tvh-addon v8.2.112
Wetek Play 2

[abga]

Got the time to load the latest Raspberry Foundation official kernel 4.9.80 - details presented in my previous post #10 :
Kernel: 4.9.80
Firmware: Mar 13 2018 18:45:03, version 6e08617e7767b09ef97b3d6cee8b75eba6d7ee0b (clean) (release)
- that comes with the offending commit reverted:
https://git.kernel.org/pub/scm/linux/ker...98f2d5f882
And on tvheadend (4.2.5) I still get these - on both SD & HD channels:

Code:

Mar 28 10:12:22 pi2s1 tvheadend[1437]: TS: Astra/11302.75H/ServusTV HD Deutschland: H264 @ #4920 Continuity counter error (total 1)
Mar 28 10:12:22 pi2s1 tvheadend[1437]: TS: Astra/11302.75H/ServusTV HD Deutschland: AC3 @ #4924 Continuity counter error (total 1)
Mar 28 10:23:06 pi2s1 tvheadend[1437]: TS: Astra/11626.5V/CNN Int.: MPEG2VIDEO @ #165 Continuity counter error (total 1)
Mar 28 10:23:31 pi2s1 tvheadend[1437]: TS: Astra/11626.5V/CNN Int.: MPEG2VIDEO @ #165 Continuity counter error (total 2)
Mar 28 10:31:33 pi2s1 tvheadend[1437]: TS: Astra/11626.5V/CNN Int.: MPEG2VIDEO @ #165 Continuity counter error (total 3)
Mar 28 10:31:37 pi2s1 tvheadend[1437]: epggrab: PSIP: ATSC Grabber - data completion timeout for 11626.5V in Astra
Mar 28 10:31:37 pi2s1 tvheadend[1437]: epggrab: EIT: DVB Grabber - data completion timeout for 11626.5V in Astra
Mar 28 10:35:43 pi2s1 tvheadend[1437]: TS: Astra/11597V/Bloomberg Europe TV: MPEG2VIDEO @ #1360 Continuity counter error (total 1)
Mar 28 10:36:15 pi2s1 tvheadend[1437]: TS: Astra/11597V/Bloomberg Europe TV: MPEG2VIDEO @ #1360 Continuity counter error (total 2)

I haven't noticed the actual frame drops that might have got resulted from these continuity counter errors  in Kodi 17.4, maybe because they are not that many and not occurring that often.
However, I moved back to the well performing kernel 4.4.50 & firmware 3ca4cf4a663c5351eaec08b29d50d6e8324981b4 and will maybe stick with it.
Getting the source code for 4.9.80 from the Raspberry Foundation, applying back the offending commit and then Linus' patch, recompiling the whole kernel in order to test it, might get a little beyond my time availability ATM.
And, there is another recent development - show stopper - for me and my Pi0 (BCM2835) multimedia usage (Kodi), reported here:
https://forum.kodi.tv/showthread.php?tid=326206

I have 3 Raspberry Pi0 boards that I dedicated solely for Multimedia - DVB streaming & Kodi, for all of them I bought a MPEG2 license and recreated the audio schematics from the Pi3B board (analogue audio buffer "sound card"). Given this situation, I'm afraid I'll stick with 4.4.50 until I retire them / donate / throw away / magic smoke will come out of them

[jahutchi]

@abga I double-checked in github for The Rasberry Pi Foundation kernel:https://github.com/raspberrypi/linux

It looks like they reverted the offending commit in the 4.14 branch:
https://github.com/raspberrypi/linux/com.../softirq.c   ( Revert "softirq: Let ksoftirqd do its job" )

But the same revert hasn't been made in their 4.9 or 4.9-stable branches:
https://github.com/raspberrypi/linux/com.../softirq.c
https://github.com/raspberrypi/linux/com.../softirq.c

Looking at the tarball link you provided: https://github.com/raspberrypi/linux/arc...130.tar.gz

This references commit 80a14a56dacb7cc2b40d5f37d00bedb0ceace130 which is a commit point in the 4.14 branch
https://github.com/raspberrypi/linux/com...b0ceace130

[abga]

@jahutchi Thanks again for your time looking into this (mess)!
I was always staying away from kernels that were not officially released by the Raspberry Foundation, mainly because I'm looking for stability and trust them with their extensive testing before the release. That's why I haven't tested the new 4.14.x branch and also not planning to.
The link I provided for the source code that was used for compiling their latest official kernel release 4.9.80+ is the result/output of the rpi-source script:
https://github.com/notro/rpi-source/wiki
See this thread - I was justme123 & was looking for the kernel headers after suddenly failing (different Module.symvers) to use the ones from https://www.niksula.hut.fi/~mhiienka/Rpi...aders-rpi/
https://www.raspberrypi.org/forums/viewt...6#p1156287
This rpi-source method is apparently the only documented way to obtain the exact source code that was used for compiling the running kernel.
Now, I cannot guarantee that the source code that resulted from running the rpi-source script was the one used in the kernel compilation and this is something only the Raspberry Foundation can check. It could be that the offending commit was actually not reverted and that means that all the investigative effort was/is in vain.

If the offending commit was indeed reverted in the Raspberry Foundation official kernel release 4.9.80+, then it will mean that only reverting it is not sufficient and maybe Linus' patch should be applied instead.
Worth to mention that I was trying this Raspberry Foundation official 4.9.80+ kernel on a Raspberry Pi 2B board, on which I was running tvheadend 4.2.5 and streaming to a remote Kodi player. On these Raspberry Pi boards the Ethernet goes also through USB (meaning that the USB subsystem was used by both the DVB adapter & Ethernet card) and the system performance (CPU) is way lower compared to the system you said you were using in a previous post "reasonably powerful Generic x86 HTPC ... 4x 1.8GHz processor cores, 4GB RAM, ION2 GPU"

I'm only able to meet you and @popcornmix here on the Kodi Forum and hope that @popcornmix will see this thread/post and check what was reported.

@popcornmix  - if you're around, please have look on what was written here. Thank you in advance!

[jahutchi]

It would be good to get some official confirmation. However, I'm pretty sure the offending commit was not reverted on the 4.9 2018-03-13 kernel.

You can browse the tree for the official rpi 2018-03-13 kernel here (via its tag in the 4.9-stable branch)
https://github.com/raspberrypi/linux/tre...20180313-1

From there you can get to kernel/softirq.c and view its history
https://github.com/raspberrypi/linux/com.../softirq.c

I can see theyve created a 20180328 tag which has the commit reverted but not sure if thats on the 4.14 branch.
https://github.com/raspberrypi/linux/com.../softirq.c

Back to my original advice
'you probably still need to stick with an older kernel for now, or figure out how to patch and recompile the kernel for your O/S.'

Ive been running with vanilla kernel 4.9.x with just the troublesome commit reverted for>3months now. and everything is perfect for me.