Continuity counter error

1st Official Post

    There is a setup with RPi2 and an DVBSky S960 USB DVB-S2 tuner (m88ds3103 chipset) running latest Libreelec 7.95.3 and Tvheadend addon in the repo. The problem described below was also seen with LE7.0.2 and an older 4.1.xxxx Tvh. No change after upgrade to latest.

    There are many short picture disturbances, at least 2-3 per minute. Meanwhile many "continuity counter error" entries can be seen in the log.
    The signal strength looks good, the BER counter is zero.
    I assume the input signal quality is good. There is a dual output twin LNB. One output is connected to this system the other is connected to a cheap Chinese set-top-box. While this RPi system suffers continuous problems on all HD channels, the other box performs well with absolute perfect reception without any disturbance over several hours.

    I have been using Tvheadend on different locations and devices for ages now, and I always experienced that TVH systems are very sensitive for disturbances and produces short picture dropouts and this hateful "continuity counter error", however not in this extent.

    What shall I do to find out the root cause and get rid of this annoying problem? Could it be a performance limitation of RPi?

    Video

    I assume you're running both Tvheadend server and client on the same Pi.
    I had the same issue with my DVBSky s960 + RPi3. Here's how you can fix it:

    1) Switch from Advanced deinterlacing to Bob. Advanced deinterlace is using a lot of RAM bandwidth and it may cause issues (especially on HD channels) when both PVR client and server are on the same Pi. This is not the best solution because Advanced looks better than Bob.
    2) Increase the "arm_uc" value (I use 12 0). The default value for Pi3 is "10 0". For Pi2 it is probably the same. Run "vcgencmd arbiter status" to check the current value.
    To make the new setting permanent add this to autostart.sh file:

    Code
    vcgencmd arbiter set arm_uc 12 0

    ^This setting completely fixed the issue for me, I didn't have to disable the Advanced deinterlacing.
    RAM overclocking will also help a bit.

    Also, see this thread - thread-4235.html
    Linux kernel 4.9.x perform poorly on the Pi. The latest LibreELEC builds are based on kernel 4.9.x. Use a build based on pre-4.9 kernel.

    Edited once, last by smp (February 13, 2017 at 11:58 PM).

    Quote from sakos


    Thank you all! I will investigate according to proposals and come back with the result.

    Here comes the findings.
    The fault comes only if both the backend and client runs on the same RPi. If I stop the client and play the stream on an external client then the playback is fine. This is very similar what smp reported.

    Open questions:
    - "vcgencmd arbiter set arm_uc 12 0" command improves the behavior but it is still present. Shall I try with other parameters?
    - "Switch from Advanced deinterlacing to Bob". There are only MMAL BOB and MMAL BOB halved options. By selecting them there is no picture. The configured HW acceleration is OMX and not MMAL. Does it matter?
    - "Linux kernel 4.9.x perform poorly on the Pi." I saw the same behavior with LE7.0.2 does it contain the same kernel? Is it worth testing with smp's custom build linked in other thread?

    Advanced (x2) deinterlace is very heavy on sdram bandwidth.
    Some PVR backends have little tolerance to being delayed and may drop packets when sdram bandwidth is heavy.

    As you have found, increasing the arm's uncached (sdram) priority can help.
    Have a read here: showthread.php?tid=269814&pid=2373475#pid2373475
    The v3d_limited is another dial you can adjust which tweaks how advanced deinterlace uses sdram.
    You can also try overclocking sdram which will help. Overclocking core and v3d may also help.

    Options are:
    Run PVR backend on a separate Pi from the one you watch.
    Switch to Bob (x2) deinterlace
    Switch to Advanced (x1) deinterlace
    Play with some of the overclock and sdram controlling settings. Perhaps we'll find a better set of defaults.

    Note: Jarvis defaulted to Bob deinterlace for HD, so switching back to Bob on Krypton should behave much like Jarvis did.

    Quote


    - "vcgencmd arbiter set arm_uc 12 0" command improves the behavior but it is still present. Shall I try with other parameters?

    No, other parameters will not improve anything.
    With the latest LE builds that use Linux kernel 4.9.x - "arm_uc 12 0" will not fix those errors.
    Use an older, pre-kernel 4.9 build (or my custom 7.95.2 build) + "arm_uc 12 0" and the errors should be gone.


    Quote


    - "Switch from Advanced deinterlacing to Bob". There are only MMAL BOB and MMAL BOB halved options. By selecting them there is no picture. The configured HW acceleration is OMX and not MMAL. Does it matter?

    Always use mmal. Never enable omx except for troubleshooting purposes.

    Quote from smp


    Use an older, pre-kernel 4.9 build (or my custom 7.95.2 build) + "arm_uc 12 0" and the errors should be gone.

    Which kernel does your custom build use?
    I can't think of a reason why an older kernel would work better, but if it does I'd like to know why.

    Quote


    Which kernel does your custom build use?

    4.8.13

    Quote


    I can't think of a reason why an older kernel would work better, but if it does I'd like to know why.

    I'd like to know this myself. I noticed the inferior performance of kernel 4.9 back in December with Milhouse build #1215. The issue is easy to reproduce as long as you have a DVB tuner connected to the Pi and PVR server/client are on the same Pi. The difference in performance is huge, with kernel 4.8 I can run this setup without a single issue (with Advanced deinterlacing enabled). With kernel 4.9 I absolutely have to disable Advanced deinterlacing (even increasing arm_uc doesn't help).

    I also tested Milhouse's kernel 4.10-RC builds and they are just as bad as 4.9.x.

    Edited once, last by smp (February 16, 2017 at 2:07 PM).

    Quote from smp


    I'd like to know this myself. I noticed the inferior performance of kernel 4.9 back in December with Milhouse build #1215. The issue is easy to reproduce as long as you have a DVB tuner connected to the Pi and PVR server/client are on the same Pi. The difference in performance is huge, with kernel 4.8 I can run this setup without a single issue (with Advanced deinterlacing enabled). With kernel 4.9 I absolutely have to disable Advanced deinterlacing (even increasing arm_uc doesn't help).

    I'll need to dig in to see exactly what changed between 4.8 and 4.9.
    4.9 kernel uses more upstream drivers, including the upstream interrupt controller. 4.8 may have still been using the downstream one (I'd have to check).
    That could mean either a difference in speed to dispatching the ISR (I would have thought that difference would be small) or a difference in precedence
    (i.e. if a USB and a timer ISR are both pending which gets dispatched first) which may have more of an effect.

    There is also a FIQ driver that USB uses.

    Can you point sakos at your build to see if it helps his issue too?

    A quick test is done with the custom build. (I checked the kernel version which was 4.8) The HW setup is Raspberry Pi2 with a DVBSky S960 USB DVB-S2 tuner. Eurosport HD channel on 0,8W

    - after installation, Continuity counter errors (CCE) and picture disturbances ~2 per minute rate
    - applying "vcgencmd arbiter set arm_uc 12 0": no significant change in CCE frequency
    - selecting BOB MMAL deinterlacing (with arm_uc at 12): significant improvement. No CCE for 10 minutes then some error appeared in the log. Anyway the system is at watchable level. :) Long term test is starting.
    - setting arm_uc back to default 10. Increased error rate to ~1 per two minutes.

    It seems that combination of arm_uc increase and lighter deinterlacing selection improves the behavior. I think this test also confirms that the root cause is a performance issue. The arm_uc increase does not help in itself. The BOB interlace helps a bit in itself.
    Nevertheless, I have to highlight that this working setup was not tested with 4.9 kernel, furthermore I have not found any difference yet between the two kernels. The error rates were similar with both kernels and arm_uc increase did not help in either case.

    Quote from smp


    RAM/GPU overclocking should help as well. Push it as far as possible.

    I will. However I am very disappointed. So far I thought RPi is very capable for a HTPC with DVB receiving capability. Now I can see it is on the edge when wathcing a single HD channel. I assume paralel recording or timeshifting can be completely forgotten.

    Quote


    Now I can see it is on the edge when wathcing a single HD channel. I assume paralel recording or timeshifting can be completely forgotten.


    Not sure about RPi2 but RPi3 is usable as a DVB receiver. However, some tweaking is obviously required to get an acceptable performance. Also, in my experience VDR is far more robust than Tvheadend, so you definitely should give it a try.

    Edited once, last by smp (February 18, 2017 at 2:49 PM).

    I am experiencing this exact same issue on my x86_64 Generic HTPC (Acer Revo 3700) which has 4x 1.8GHz CPU Cores, 4GB RAM & 1TB SATAIII HDD.
    I'm running the latest HTS Tvheadend 4.1.2415 ~ LibreELEC Tvh-addon v8.1.109, with 2x DVBSky S960 USB DVB-S2 adapters.

    If I upgrade to one of the latest beta releases 7.95.1, 7.95.2, 7.95.3 then the picture breaks up (i.e. goes blocky for a second or so) every couple of minutes when watching either Live TV or recording. The issue is worse for HD channels but does also occur on SD Channels.

    When the picture goes blocky I receive Continuity Counter errors in the logfile for example:

    Code
    2017-02-06 21:01:51.469 [WARNING] TS: Freesat/11097V/ITV HD: H264 @ #2310 Continuity counter error (total 16)
2017-02-06 21:01:51.469 [WARNING] TS: Freesat/11097V/ITV HD: MPEG2AUDIO @ #2313 Continuity counter error (total 2)
2017-02-06 21:06:03.462 [WARNING] TS: Freesat/11097V/ITV HD: H264 @ #2310 Continuity counter error (total 17)
2017-02-06 21:06:19.164 [WARNING] TS: Freesat/11097V/ITV HD: H264 @ #2310 Continuity counter error (total 18)
2017-02-06 21:06:19.164 [WARNING] TS: Freesat/11097V/ITV HD: AC3 @ #2311 Continuity counter error (total 5)
2017-02-06 21:06:19.164 [WARNING] TS: Freesat/11097V/ITV HD: MPEG2AUDIO @ #2313 Continuity counter error (total 3)
2017-02-06 21:06:50.707 [WARNING] TS: Freesat/11097V/ITV HD: H264 @ #2310 Continuity counter error (total 21)
2017-02-06 21:07:40.201 [WARNING] TS: Freesat/11097V/ITV HD: H264 @ #2310 Continuity counter error (total 23)
2017-02-06 21:09:05.369 [WARNING] TS: Freesat/11097V/ITV HD: H264 @ #2310 Continuity counter error (total 24)
2017-02-06 21:09:05.369 [WARNING] TS: Freesat/11097V/ITV HD: MPEG2AUDIO @ #2313 Continuity counter error (total 4)

    If I downgrade to LE 7.90.009 alpha as stipulated in this post:thread-3665.html then I do not have any problems whatsoever.

    I wonder whether it relates to the move from a 4.8.12 kernel to 4.9.x since the problem ONLY occurs when I upgrade to anything later than 7.90.009 :(

    I was previously running Ubuntu 14.04 on this very same machine (i.e. same hardware & DVB Cards) and never had any disturbances in the picture quality, or Continuity Counter errors in the logfile... I know that because I took a full backup before moving away from Ubuntu. So was able to go back and examine my previous /var/log/syslog.x files - not a single Continuity Counter Error whatsoever!

    I hope this will be fixed before the production release as I'd rather not stay on the alpha release forever.

    Also.....I wonder whether it's possible to swap in the 4.8.12 kernel and run this against the latest 7.95.3 beta release to identify whether the kernel is indeed the point at issue. Could that be done by simply swapping the KERNEL & KERNEL.md5 files in from the alpha 9 release into the /flash folder (after mounting the vfat partition r/w). I'd be happy to give that a go if someone could confirm it won't break my system. If not, maybe there are other things I could try to help debug the issue?

    Note: I've also posted the same findings in response to the thead here: thread-3665.html before then noticing this thread which seems to have picked up more of a head of steam.