Tvheadend

Same here, take a look to the screenshoots:

https://tvheadend.org/issues/2194#change-9703

no cc errors when all tuners are in use or the bckground searching is switched off.

br
Alfred

I have already tried with disabling "Idle scan" and I have also made sure that "Power save" is off to keep the tuners/LNB:s on all the time.

However, disabling "Idle scan" caused the EPG updating to not work properly so I have to keep "Idle scan" on to be able to get the EPG populated up to one week ahead.

My problem with CC errors happens even if background tuning is not going on. It is very easy to reproduce by enabling every 2nd tuner again and then start enough XBMC clients on HD channels so that any of the secondary tunes is being used and voila! CC errors starts to appear immediately.
Disable every secondary tuner and CC errors are gone. Strange...

I have one DD Octopus and 3 DuoFlex S2 cards, i.e., 6 adapters.
These are connected to a 8x16 diseqc switch using excessively long cables, so my signal strength is not great (64-68%) and SNR is acceptable (52-70%).
Adapter 1 is not doing well, it only works with SD, FTA transmission, the other 5 adapters take Astra 2 HD (FTA) without problem, either 1 or 5 muxes at the same time with signal strength and SNR both "brown" (<66%).
So I am not entirely sure I can spot your symptoms for FTA.

Note: I have Ubuntu 12.04 with the default ddbridge driver. I stopped with media-experimental because I would have to reinstall the custom ddbridge every time Ubuntu would push a new kernel.

However, I do have CC errors up the wazoo with Astra 3 (Canal Digitaal). The V muxes work well (11739V, 11856V and 12129V) but 12187H is bad. Even with 70% signal and 72% SNR and transport errors staying 0, I get slews of Continuity Errors watching e.g. Veronica HD.
And I noticed that the encrypted transmissions work better on adapter 0 and 2, whereas they have trouble decrypting on adapter 3 and 5. (1 and 4 are having SNR issues, I have to check the cables).

At the end of June this seemed to have worked with a 3.9 version I did not take note of, but now (1285 and 1353) it is bad (1 per minute or clusters of 5 in 30 seconds).

A friend of mine has an v6 card and he had similar problems, I did 2 things that apparently solved it.
1) placed a fan above the tuner (demod and fpga can become very hot).
2) isolated the f-connector outputs from the pc chassis. If your psu is not so well designed, interferrence currents can flow to your demodulator/tuner via the pc case.

That was specific for Digital Devices, but I've seen that OTA epg grabbing can also cause cc errors on my TBS tuners (TBS6985).
Now, I modded/hacked tvheadend a bit so it only does OTA grabbing at night (4am-5am), cc errors are gone since.

If you want to test this, its the 3.9_mod branch from here: https://github.com/Glenn-1990/tvheadend/tree/3.9_mod
Be warned, it also includes some other mods and fixes and is based on a older(3.9.519) vesion (latest builds seems very unstable for me).

As you seems to be interested in the TBS6985, it's currently only working stable with the OTA hack, but I'm going to switch to the open source drivers to see how they cope with 24hr/24hr OTA grabbing combinated with lots of recordings.

Some research would tell you OP this isn't "Very interesting discovery", it's vety old problem that's been documented by people for over 2 years.
There are various fixes out there that fix this issue except in the worst cases where a different motherboard will be your only solution.

FTR, the open source 6985 drivers are a complete load of rubbish, don't touch them, unstable, wierd behaviour! As opposed to the 6981 drivers which are like unicorn magic dust.

Robert E Rob:
If you look on my post history you will see that I have been well aware of the CC problems before I did this post.
I have done extensive research for over a year all over the web in different forums about these problems that quite many people seem to have (like me).
I have seen all kinds of solutions (or well, attempts to solve the problems) and some people have for example tested motherboards from three different manufacturers without solving the problem. (See for example TBS forum post http://www.tbsdtv.com/forum/viewtopic.php?f=142&t=8823&p=31442&hilit=motherboard#p31442)

What I felt was a new and somewhat interesting discovery was the fact that in my case it is ALWAYS the secondary tuner on each card that is causing this and by disabling every secondary tuner I am able to TOTALLY get rid of the CC problems. Neither EPG scanning or anything else is now "disturbing" in anyway to create CC errors, all works smooth and flawless.
It was also interesting to see that I found another person with IDENTICAL problem but using a totally different card (TBS-forum again http://www.tbsdtv.com/forum/viewtopic.php?f=142&t=8868).

Anyway, I think I'll try the suggestion from "glenn ch" and isolate the F-connectors from the chassi to avoid disturbing ground currents. I have a pretty good grounding system with lightning protection on the incoming cables and when I measured my grounding system I found some very strange grounding current/voltage differential between the incoming earthing ground and the chassi on my TV-PC. These disturbing grounding currents appear ONLY when the TV-PC is turned on. When I measure the voltage differential between the PC chassi and "true" earthing ground I can easily see how the voltage differential starts at zero when I turn the PC-TV on and then the voltage differential increases during the first 30 seconds up to approx 9-10 volts. I found some threads on the web explaining it is the decoupling capacitors in the PSU causing this due to how PSU:s in PC:s are constructed.
(See for example the picture in the post at http://www.eevblog.com/forum/beginners/connecting-system-ground-to-mains-earth/msg27677/?PHPSESSID=ae1dc53fbfc6945c55291ece003dd365#msg27677)

So I think my first attempt will be to try to isolate the F-connectors on the tuner cards from the PC-chassi.

Glenn Martinez ch: may I ask how you did the isolation of the F-connectors on the tuner cards?

Robert E Rob again: So you have tested Luis' open source drivers for TBS6985 and your experience is that they do not work good at all? You prefer TBS own drivers?

The hint with the power supply seems to be good. :-)

I replaced my 60W mini-ITX-supply against a 160/200W picoPSU with 12V/10Amps power adapter and now I can activate background searching without disturbing my viewing. Looks good atm.

br
Alfred

Robert E Rob, I already switched to crazycat drivers from here https://bitbucket.org/CrazyCat/linux-tbs-drivers
I believe that inludes the open source drivers for the TBS6985?
It seems working ok on the first sight.

crazy XXX fin
The dummy solution, removed the metal bracket and taped in the connectors :p

@Both
My first tuner was a cine s2 v5 (ngene) some years back, lets say around 2010. It was working fine until my provider (Canal digital NL) switched some transponders to 8psk modulation, from then on the second tuner was dropping data like hell (for the particular 8psk channels).

I got into contact with a digital devices dev and he couldn't reproduce it as the FTA 8psk transponders doesn't seems to suffer from this.
The problem was that I was only having this issue on encrypted channels wich he couldn't watch, so eventually he said that it was a bug in ffdecsa/mdapi.
Nonsense offcource as other tuners work fine, I believe that it's a firmware or even a hardware bug (demodulator chip).

This seems very similar, but as far as I know this is limited to the NGENE based tuners!

He he I was also thinking of that quick and dirty solution. Thanks for confirming that it was that you actually did. :-)

The Cine S2 V6.5 cards I have are not "ngene" based but recognized as "ddbridge" modules in the kernel (I guess).

lspci -v shows the following data in my system:

===============
02:00.0 Multimedia controller: Digital Devices GmbH Octopus DVB Adapter
Subsystem: Digital Devices GmbH Cine S2 V6.5 DVB adapter
Flags: bus master, fast devsel, latency 0, IRQ 44
Memory at fbcf0000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 3
Capabilities: [70] MSI: Enable+ Count=1/2 Maskable- 64bit+
Capabilities: [90] Express Endpoint, MSI 00
Capabilities: [100] Vendor Specific Information: ID=0000 Rev=0 Len=00c
Kernel driver in use: ddbridge
Kernel modules: ddbridge

03:00.0 Multimedia controller: Digital Devices GmbH Octopus DVB Adapter
Subsystem: Digital Devices GmbH Cine S2 V6.5 DVB adapter
Flags: bus master, fast devsel, latency 0, IRQ 46
Memory at fbbf0000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 3
Capabilities: [70] MSI: Enable+ Count=1/2 Maskable- 64bit+
Capabilities: [90] Express Endpoint, MSI 00
Capabilities: [100] Vendor Specific Information: ID=0000 Rev=0 Len=00c
Kernel driver in use: ddbridge
Kernel modules: ddbridge ===============

I am confused though since I am not sure I am actually using the proper and latest drivers?

dmesg output shows the following:

==============
[ 2.739975] DDBridge driver detected: Digital Devices Cine S2 V6.5 DVB adapter
[ 2.740039] ddbridge 0000:02:00.0: irq 44 for MSI/MSI-X
[ 2.753438] DVB: registering new adapter (DDBridge)
[ 2.753440] DVB: registering new adapter (DDBridge)
[ 2.753441] DVB: registering new adapter (DDBridge)
[ 2.753442] DVB: registering new adapter (DDBridge)
[ 2.969899] ddbridge 0000:02:00.0: DVB: registering adapter 0 frontend 0 (STV090x Multistandard)...
[ 3.005091] ddbridge 0000:02:00.0: DVB: registering adapter 1 frontend 0 (STV090x Multistandard)...
[ 3.157103] ddbridge 0000:02:00.0: DVB: registering adapter 2 frontend 0 (STV090x Multistandard)...
[ 3.193208] ddbridge 0000:02:00.0: DVB: registering adapter 3 frontend 0 (STV090x Multistandard)...
[ 3.194393] DDBridge driver detected: Digital Devices Cine S2 V6.5 DVB adapter
[ 3.194456] ddbridge 0000:03:00.0: irq 46 for MSI/MSI-X
[ 3.199940] DVB: registering new adapter (DDBridge)
[ 3.199941] DVB: registering new adapter (DDBridge)
[ 3.199943] DVB: registering new adapter (DDBridge)
[ 3.199944] DVB: registering new adapter (DDBridge)
[ 3.373076] ddbridge 0000:03:00.0: DVB: registering adapter 4 frontend 0 (STV090x Multistandard)...
[ 3.409079] ddbridge 0000:03:00.0: DVB: registering adapter 5 frontend 0 (STV090x Multistandard)...
[ 3.585110] ddbridge 0000:03:00.0: DVB: registering adapter 6 frontend 0 (STV090x Multistandard)...
[ 3.621104] ddbridge 0000:03:00.0: DVB: registering adapter 7 frontend 0 (STV090x Multistandard)...

====

BUT if I run a more detailed dmesg output without filtering on "ddb" I see some lines with for example:

=========
[ 2.969890] stv6110x attach: Attaching STV6110x
[ 2.969893] attach tuner input 0 adr 60
[ 2.969899] ddbridge 0000:02:00.0: DVB: registering adapter 0 frontend 0 (STV090x Multistandard)... ============

Is STV6110x the same as STV090x?

Also, I am unsure what driver to actually use since the page http://shop.digital-devices.de/epages/62357162.sf/?ObjectPath=/Shops/62357162/Categories/DownloadsNew1/Linux_Unterstuetzung_fuer_Digital_Devices_Produkte first shows a download link to a driver file with version 0.9.15a but then further down on that page Digital Devices shows how to download the driver from http://linuxtv.org/hg/~endriss/media_build_experimental/

Are the drivers on those 2 places the same driver and if not, how do I install the 0.9.15a-driver?

And thirdly, what command to use to find out what version of driver I am actually using?

STV6110x is the tuner and the STV090x is the demodulator ;-)

Maybe you can try the crazycat drivers?
Originally for tbs cards but it also supports DD and other brands.
https://bitbucket.org/CrazyCat/linux-tbs-drivers

If that doesn't work, you can add an 'issue' so crazycat is aware of it (he seems very helpfull)

I tested the CrazyCat drivers and both dmesg and lspci output seems to show that the two tuner cards are found and recognized by the kernel but when I start TVH there are no adapaters available.

I´ll make a new attempt tonight when I am back home and collect more proper logs.

When I looked at the status stream display, I noticed that a switch of channels sometimes results in 2 activities: a "scan" plus the new channel that I selected. When this happens, the new channel fails to tune, or it results in a badly tuned adapter with CC errors.
If there is no "scan" kicked off, the stream tunes correctly, invariably.

Now, I am testing this on Canal Digitaal, Astra 3, decrypted with Oscam via a nodmx connection (mode 4). It also occurs with mode 2.
Could it be that the quick "scan" upsets the decrypt service?

I had reception on RTL7 (adapter 2, 11856V) and switched to Veronica (adapater 2, 12187H).
Why is it quickly doing a scan of 11856V on adapter 3?

Aug 25 12:52:13 sat tvheadend[19569]: subscription: "10.29.1.46 [ XBMC Media Center ]" unsubscribing from "RTL7 HD", hostname="10.29.1.46", username="<N/A>", client="XBMC Media Center" 
Aug 25 12:52:13 sat tvheadend[19569]: capmt: Removing CAPMT Server from service "RTL7 HD" on adapter 2
Aug 25 12:52:13 sat tvheadend[19569]: mpegts: 11856V in 23.5E - tuning on STV090x Multistandard : DVB-S #3
Aug 25 12:52:14 sat tvheadend[19569]: subscription: 'scan' subscribing to mux, weight: 1, adapter: 'STV090x Multistandard : DVB-S #3', network: '23.5E', mux: '11856V', hostname: '<N/A>', username: '<N/A>', client: '<N/A>'
Aug 25 12:52:14 sat tvheadend[19569]: mpegts: 12187H in 23.5E - tuning on STV090x Multistandard : DVB-S #2
Aug 25 12:52:15 sat tvheadend[19569]: capmt: Starting CAPMT server for service "Veronica/DisneyXD HD" on adapter 2 seq 0x0064
Aug 25 12:52:15 sat tvheadend[19569]: subscription: "10.29.1.46 [ XBMC Media Center ]" subscribing on "Veronica/DisneyXD HD", weight: 150, adapter: "STV090x Multistandard : DVB-S #2", network: "23.5E", mux: "12187H", provider: "M7 Group", service: "Veronica/DisneyXD HD", hostname="10.29.1.46", username="<N/A>", client="XBMC Media Center" 
Aug 25 12:52:17 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: H264 @ #517 Continuity counter error (total 1)
Aug 25 12:52:18 sat tvheadend[19569]: mpegts: 11856V in 23.5E scan complete
Aug 25 12:52:18 sat tvheadend[19569]: subscription: "scan" unsubscribing
Aug 25 12:52:20 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD Transport error indicator (total 1)
Aug 25 12:52:20 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: MPEG2AUDIO @ #105 Continuity counter error (total 1)
Aug 25 12:52:24 sat tvheadend[19569]: descrambler: cannot decode packets for service "Veronica/DisneyXD HD" 
Aug 25 12:52:30 sat tvheadend[19569]: capmt: Removing CAPMT Server from service "Veronica/DisneyXD HD" on adapter 2
Aug 25 12:52:30 sat tvheadend[19569]: mpegts: 12187H in 23.5E - tuning on STV090x Multistandard : DVB-S #3
Aug 25 12:52:30 sat tvheadend[19569]: capmt: Starting CAPMT server for service "Veronica/DisneyXD HD" on adapter 3 seq 0x0065
Aug 25 12:52:30 sat tvheadend[19569]: subscription: "10.29.1.46 [ XBMC Media Center ]" subscribing on "Veronica/DisneyXD HD", weight: 150, adapter: "STV090x Multistandard : DVB-S #3", network: "23.5E", mux: "12187H", provider: "M7 Group", service: "Veronica/DisneyXD HD", hostname="10.29.1.46", username="<N/A>", client="XBMC Media Center" 
Aug 25 12:52:34 sat tvheadend[19569]: mpegts: 12187H in 23.5E scan complete
Aug 25 12:52:34 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: H264 @ #517 Continuity counter error (total 1)
Aug 25 12:52:39 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: MPEG2AUDIO @ #105 Continuity counter error (total 1)
Aug 25 12:52:45 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: H264 @ #517 Continuity counter error (total 16)
Aug 25 12:52:45 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: TELETEXT @ #37 Continuity counter error (total 1)
Aug 25 12:52:47 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD Transport error indicator (total 1)
Aug 25 12:52:56 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: H264 @ #517 Continuity counter error (total 30)
Aug 25 12:52:56 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: TELETEXT @ #37 Continuity counter error (total 2)
Aug 25 12:53:03 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: MPEG2AUDIO @ #105 Continuity counter error (total 3)
Aug 25 12:53:07 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: H264 @ #517 Continuity counter error (total 49)
Aug 25 12:53:10 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: TELETEXT @ #37 Continuity counter error (total 3)
Aug 25 12:53:20 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: H264 @ #517 Continuity counter error (total 64)
Aug 25 12:53:21 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: MPEG2AUDIO @ #105 Continuity counter error (total 7)
Aug 25 12:53:27 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD Transport error indicator (total 2)
Aug 25 12:53:28 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: TELETEXT @ #37 Continuity counter error (total 5)
Aug 25 12:53:31 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: H264 @ #517 Continuity counter error (total 81)
Aug 25 12:53:34 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: MPEG2AUDIO @ #105 Continuity counter error (total 11)
Aug 25 12:53:42 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: H264 @ #517 Continuity counter error (total 94)
Aug 25 12:53:49 sat tvheadend[19569]: descrambler: cannot decode packets for service "Veronica/DisneyXD HD" 
Aug 25 12:53:53 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: H264 @ #517 Continuity counter error (total 108)
Aug 25 12:53:53 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: TELETEXT @ #37 Continuity counter error (total 6)
Aug 25 12:53:53 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: MPEG2AUDIO @ #105 Continuity counter error (total 13)
Aug 25 12:54:00 sat tvheadend[19569]: descrambler: cannot decode packets for service "Veronica/DisneyXD HD" 
Aug 25 12:54:02 sat tvheadend[19569]: capmt: Removing CAPMT Server from service "Veronica/DisneyXD HD" on adapter 3
Aug 25 12:54:02 sat tvheadend[19569]: mpegts: 12187H in 23.5E - tuning on STV090x Multistandard : DVB-S #4
Aug 25 12:54:03 sat tvheadend[19569]: capmt: Starting CAPMT server for service "Veronica/DisneyXD HD" on adapter 4 seq 0x0066
Aug 25 12:54:03 sat tvheadend[19569]: subscription: "10.29.1.46 [ XBMC Media Center ]" subscribing on "Veronica/DisneyXD HD", weight: 150, adapter: "STV090x Multistandard : DVB-S #4", network: "23.5E", mux: "12187H", provider: "M7 Group", service: "Veronica/DisneyXD HD", hostname="10.29.1.46", username="<N/A>", client="XBMC Media Center" 
Aug 25 12:54:12 sat tvheadend[19569]: mpegts: 12187H in 23.5E - scan no data, failed
Aug 25 12:54:14 sat tvheadend[19569]: capmt: Removing CAPMT Server from service "Veronica/DisneyXD HD" on adapter 4
Aug 25 12:54:14 sat tvheadend[19569]: mpegts: 12187H in 23.5E - tuning on STV090x Multistandard : DVB-S #5
Aug 25 12:54:14 sat tvheadend[19569]: capmt: Starting CAPMT server for service "Veronica/DisneyXD HD" on adapter 5 seq 0x0067
Aug 25 12:54:14 sat tvheadend[19569]: subscription: "10.29.1.46 [ XBMC Media Center ]" subscribing on "Veronica/DisneyXD HD", weight: 150, adapter: "STV090x Multistandard : DVB-S #5", network: "23.5E", mux: "12187H", provider: "M7 Group", service: "Veronica/DisneyXD HD", hostname="10.29.1.46", username="<N/A>", client="XBMC Media Center" 
Aug 25 12:54:15 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD Transport error indicator (total 1)
Aug 25 12:54:15 sat tvheadend[19569]: pat: invalid checksum (len 60, errors 1)
Aug 25 12:54:15 sat tvheadend[19569]: eit: invalid checksum (len 333, errors 1)
Aug 25 12:54:15 sat tvheadend[19569]: pmt: invalid checksum (len 91, errors 1)
Aug 25 12:54:15 sat tvheadend[19569]: pmt: invalid checksum (len 160, errors 1)
Aug 25 12:54:15 sat tvheadend[19569]: pmt: invalid checksum (len 150, errors 1)
Aug 25 12:54:15 sat tvheadend[19569]: pmt: invalid checksum (len 193, errors 1)
Aug 25 12:54:16 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: H264 @ #517 Continuity counter error (total 1)
Aug 25 12:54:16 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: MPEG2AUDIO @ #105 Continuity counter error (total 1)
Aug 25 12:54:16 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: TELETEXT @ #37 Continuity counter error (total 1)
Aug 25 12:54:16 sat tvheadend[19569]: pmt: invalid checksum (len 249, errors 1)
Aug 25 12:54:16 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: H264 @ #517 Corrupted PES header (errors 1)
Aug 25 12:54:16 sat tvheadend[19569]: pmt: invalid checksum (len 86, errors 1)
Aug 25 12:54:16 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD: TELETEXT @ #37 Corrupted PES header (errors 1)
Aug 25 12:54:16 sat tvheadend[19569]: pmt: invalid checksum (len 355, errors 1)
Aug 25 12:54:16 sat tvheadend[19569]: pmt: invalid checksum (len 91, errors 1)
Aug 25 12:54:17 sat tvheadend[19569]: pmt: invalid checksum (len 111, errors 1)
Aug 25 12:54:17 sat tvheadend[19569]: pmt: invalid checksum (len 253, errors 1)
Aug 25 12:54:21 sat tvheadend[19569]: pmt: invalid checksum (len 172, errors 1)
Aug 25 12:54:21 sat tvheadend[19569]: pmt: invalid checksum (len 172, errors 1)
Aug 25 12:54:22 sat tvheadend[19569]: descrambler: cannot decode packets for service "Veronica/DisneyXD HD" 
Aug 25 12:54:24 sat tvheadend[19569]: mepgts: 12187H in 23.5E - scan needs more time
Aug 25 12:54:24 sat tvheadend[19569]: mpegts: 12187H in 23.5E scan complete
Aug 25 12:54:26 sat tvheadend[19569]: TS: 23.5E/12187H/Veronica/DisneyXD HD Transport error indicator (total 203)
Aug 25 12:54:26 sat tvheadend[19569]: eit: invalid checksum (len 267, errors 9)
Aug 25 12:54:27 sat tvheadend[19569]: pmt: invalid checksum (len 189, errors 6)
Aug 25 12:54:27 sat tvheadend[19569]: pmt: invalid checksum (len 160, errors 8)
Aug 25 12:54:27 sat tvheadend[19569]: pmt: invalid checksum (len 93, errors 5)
Aug 25 12:54:27 sat tvheadend[19569]: pmt: invalid checksum (len 355, errors 9)
Aug 25 12:54:27 sat tvheadend[19569]: pmt: invalid checksum (len 86, errors 4)
Aug 25 12:54:28 sat tvheadend[19569]: pmt: invalid checksum (len 249, errors 6)
Aug 25 12:54:28 sat tvheadend[19569]: pmt: invalid checksum (len 182, errors 6)
Aug 25 12:54:28 sat tvheadend[19569]: pat: invalid checksum (len 60, errors 4)
Aug 25 12:54:29 sat tvheadend[19569]: nit: invalid checksum (len 480, errors 1)
Aug 25 12:54:30 sat tvheadend[19569]: capmt: Removing CAPMT Server from service "Veronica/DisneyXD HD" on adapter 5
Aug 25 12:54:30 sat tvheadend[19569]: mpegts: 12187H in 23.5E - tuning on STV090x Multistandard : DVB-S #0
Aug 25 12:54:30 sat tvheadend[19569]: capmt: Starting CAPMT server for service "Veronica/DisneyXD HD" on adapter 0 seq 0x0068
Aug 25 12:54:30 sat tvheadend[19569]: subscription: "10.29.1.46 [ XBMC Media Center ]" subscribing on "Veronica/DisneyXD HD", weight: 150, adapter: "STV090x Multistandard : DVB-S #0", network: "23.5E", mux: "12187H", provider: "M7 Group", service: "Veronica/DisneyXD HD", hostname="10.29.1.46", username="<N/A>", client="XBMC Media Center" 
Aug 25 12:54:33 sat tvheadend[19569]: mpegts: 12187H in 23.5E scan complete

Now, when I disable "Idle scan" on 23.5E, I do not see this extra "scan" and the channel switch works.
Of course, I want my OTA EPG, so I've scheduled a mux scan for the relevant muxes at night. Lets see if that works.

More intensive Google-searching and I found this interesting page:

http://www.gymalp.ch/~eumetcast/DVBS2S2 and he is testing DVB-S2 signals with TBS-6925 PCIe cards

It looks like his solution was to minimize disk IOwait as much as possible:

"During the last 18 days EUMETCast receiver Kallisto has been running with the new solution. It was doing exactly the same tasks as Terra and Luna. Kallisto has not lost a single packet (see below) while the two other receivers had a total of nine events with severe packet loss caused by IOwaits. Writing all files from tc-recv to a tmp file system and transfer them every 5 minutes to HDD has been implemented on Terra and Luna today."

I measured the voltage differential between the chassi of my TV server and my "true" ground (3 copper ground rods around the house connected to the main earth buss bar) and before I turn on my TV server I measure approx 0.5 ohms between chassi and ground and no voltage differential.

When I turn on my TV server it jumps to approx 7 ohms and 4 mV as soon as TVH starts (i.e. activates the tuner cards). The question is if this quite small voltage differential is big enough to cause noise/lost packets etc on the tuner cards. It is definately the construction of PC power supplies causing this. I see similar small ground differentials between "true" ground and PC chassi on all my other computers in the house.

I´ll try to do the isolation of the F-connector outputs from the TV server chassi and see if it helps. I´ll report back but reading the link on my previous post above I am more inclined to think this really is an IOwait-issue causing packets from the TC streams being lost.

Hmmm I am getting very confused now... I myself was quite convinced that this is either a HW error or a Linux driver problem...

However, just for fun I am currently testing to run TVH on a version from earlier this spring since I remember not having these CC problems back in Apr/May.

So I pulled the version 3.8.636 from the repo and I have now been running for about 5 hours with all 8 tuners enabled and been using 5-6 of them at the same time on HD channels only and almost NO CC errors at all?! Most of the very few CC errors (like 10 in total for 5 hours) did show up during channel switching.

Is it really not TVH being one possible source for the CC errors?

As soon as I switch back to the latest commit, 3.9.1353 I get the CC errors again on every 2nd tuner and then if I disable every 2nd tuner the CC errors disappear...

Try my suggestion from y'day:

Now, when I disable "Idle scan" on 23.5E, I do not see this extra "scan" and the channel switch works.
Of course, I want my OTA EPG, so I've scheduled a mux scan for the relevant muxes at night. Lets see if that works.

It has worked well so far.

crazy XXX Fin
Yes, now it looks like some issue with OTA grabbing in background.

Additionally you can add a line "goto done;" here and compile:
https://github.com/tvheadend/tvheadend/blob/master/src/epggrab/otamux.c#L478
This to be completely sure that ota never kicks, because it seems to kick in even if I disable it in config..

Ok but I have tried with both disabling and enabling the Idle Scan and I am convinced that my CC errors are not caused by the OTA EPG grabbing events.

I get CC errors DIRECTLY if I am watching a HD channel on one XBMC client and then start watching another HD channel on a XBMC client on another computer and that second XBMC uses a secondary tuner (2nd, 4th, 6th and the 8th tuner). These CC errors continues then until I either stop watching the HD channel, switch to a SD channel or if I am lucky enough and TVH choses a primary tuner (1st, 3rd, 5th and the 7th tuner).

So in my case the CC errors are not coming and going but they are consistently showing up as soon as I watch more than one HD channels simultaneously and TVH uses one of the 2ndary tuners.

However, yesterday I removed both tuner cards and unscrewed cards from the mounting brackets. I put some isolation tape on the F-connectors on the cards. I mounted back the two main cards onto the motherboard and then I kept the two secondary addon cards lying on the floor just next to the chassi (isolated the bottom of the circuit board also in case it would come in contact with the chassi).

Guess what! NOT A SINGLE CC ERROR since last night?!

I have been running on tuner 7 (a primary tuner) and tuner 8 (a secondary tuner) continously with HD channels on both. I even tried to start 2 more HD channels via some tablets and still no CC errors...

Could be my graphics card mounted in the PCIe x16 slot just next to the tuner cards that is causing RF interference with the tuner cards, OR it could be the fact that now the F-connectors are isolated from the PC chassi or a combo of both of them.
When I measure the F-connector body and PC chassi it still indicates low resistance (around 0.3 to 0.4 ohms only) connection so I am not sure if it was this step that actually helped.

Anyway, I´ll keep it running like this with totally open PC chassi and the secondary tuners lying next to the chassi and the F-connectors "isolated" from the chassi.
After that I´ll remove the graphics card and try with another type of graphics card mounted in a normal PCI-slot which will be further away from the tuner cards compared to the graphics card sitting in the PCIe x16-slot OR a combination of those two.
I might even try with rebuilding the TV-PC and use a motherboard with built-in graphics and PCIe x1-slots as far possible away from the middle of the motherboard to avoid EMI interference from graphics and CPU. My current motherboard is a GA-Z77P-D3 (rev. 1.0) which has no built-in graphics.

Reporting back soon again. :-)

Hmmm I'm thinking of testing with either PCI-E x1 raiser cards/cables to get out the tuner cards from the motherboard and the graphics card:
http://eshop.sintech.cn/flexible-pci-express-x1-riser-card250mm-p-602.html

or even an external PCI-e x1 expansion borad that I build in to a separate metal shielded box:
http://eshop.sintech.cn/pcie-express-3port-1x-multiplier-riser-cable-diy-bitcoin-miner-p-1011.html
I am not sure though if the speed needed for DVB-S2 PCI-e tuner cards will be a problem when using expansion boards like this one.

Alright, 24 hours now and only one single tiny Continuity Counter Error! See attached picture. This is sooooo nice to see! :-)

I am getting more and more convinced that it is either EMI interference from the CPU/motherboard OR the graphics card (or a combo of the both) . Maybe the fact that I have isolated the output connectors from the chassi now (somewhat) helps as well. See attached pictures.

Next step is to purchase either the PCI-e x1 expansion board or the PCI-E x1 raiser cards/cables and build a small metallic box outside the TV-PC where the tuner cards can be kept.

A third solution to test is to test with a motherboard that has the PCI-E x1 slots away from the center of the motherboard (CPU area) as possible and has built-in graphics so that the graphics card is not using the same PCI buss that the tuner cards are.

Right, I'll add to this as I can rule out a couple of things for you guys.
I have had this card as well as the 6981.
In response to Luis' drivers, the 6981 ones are fantastic, work perfectly Vs the TBS ones which are shockingly bad and just generally broken on linux with tvheadend.
The drivers from Luis on the 6985 are as bad or worse than the TBS drivers for the 6981, unuseable, errors everywhere, bad signal, just generally wierd. Did a few installs, same results. I've had both cards for ages so not to sound arrogant but they are just rubbish.

On the front of the PSU interfering with the cards, I call nonsense on that.
My setup is a PicoPSU where the power converting gets done at the ATX connector, miles away from the cards, the cards are also on a riser. This is a red herring I assure you.

On the front of someone mentioning only Vertical polarity frequencies exhibiting problems, this means nothing. In fact it likely does mean "something" but not with respect to the cards, that is a skew issue, or dish alignment issue. The installer should make sure there is a balance between very good Horizontal AND Vertical polarity signals, this is the problem with rubbish installers, they check 1 channel on a usually weak frequency and assume all is well, no you have to check a few channels on weak frequencies for BOTH horizontal and vertical and get a trade off.

You'll find lots of info on dedicated satellite forums dicsussing the kind of thing being discussed here, but very little useful info on TBS of any PC based card forum be it official or otherwise.
If you want to find some answers, you'll have to look on STB box forums (Not Sky/Virgin, but the non official "dodgy" boxes)

Some people have mentioned things like the boxes receving TOO MUCH voltage causing V/H polarity signals to be a problem, only for it to be a skew issues, there's a couple of boxes where this is a problem but there's no inherrent bug in the 6985 that causes this, I also have weak V polarity frequencies, but this is after an installer messing around with adding extra lines and not aligining the the new LNB I gave him to fit.

Like said earlier

1. Put it in a 1x port, or set a higher port to 1x.
2. Set MSI interrupts.
3. There's a few motherboards that just don't detect these cards.
4. Recent versions of tvheadend have something wrong with them, I don't know what, but there's lots of pmt checksum errors that are certainly not genuine, or are a result of something bad in tvheadend being introduced in the last 3-4 months.
5. TBS drivers for the 6985 work absolutely fine.

Not setting MSI interrupts is the usual culprit for problems and remedy in 2 minutes.

If you are getting improved results by isolating the card in any way, then the problem is that you had a rubbish signal to start with, bad wiring, alignment issue, dodgy LNB, bad skew. In the situation where your input signal is very weak to start with, then yes of course isolating it may help some amount, but you'd be much better off just getting your dish related hardware and bits sorted, because THAT is your problem.

Crazy Fin wrote:

Alright, 24 hours now and only one single tiny Continuity Counter Error! See attached picture. This is sooooo nice to see! :-)

I am getting more and more convinced that it is either EMI interference from the CPU/motherboard OR the graphics card (or a combo of the both) . Maybe the fact that I have isolated the output connectors from the chassi now (somewhat) helps as well. See attached pictures.

Next step is to purchase either the PCI-e x1 expansion board or the PCI-E x1 raiser cards/cables and build a small metallic box outside the TV-PC where the tuner cards can be kept.

A third solution to test is to test with a motherboard that has the PCI-E x1 slots away from the center of the motherboard (CPU area) as possible and has built-in graphics so that the graphics card is not using the same PCI buss that the tuner cards are.

Your signal strength is low to being with and SNR is borderline acceptable. You are in the real of just not getting CC/PMT/BER errors in good to reasonable weather, you chuck some fairly heavy rain outside and your CC erros will be back with avengence. You need to improve your dish needs checking over 100% with results like that.
A lazy installer will often say "it's all ok", when it isn't you need to make damn sure they check a few channels on difference frequencies and polarities.

Your solution is just making the best of a bad setup, alignment, skew, EMI is a fact of life and it does affect satellite signals negatively if they are bad to begin with.

@ Rob Rob, the CC errors from Crazy Fin where we are talking about are from a cine s2 tuner, not?
Yes I've a tbs 6985 tuner and it works fine except from some cc errors when ota epg grab is running, but nothing to worry about :-)

@ Crazy Fin
Pcie x1 slots are usually placed next to the graphics card, so the tuner should be designed to handle that ;-)
And there already is a shield around the tuner components itself.
Keep also in mind that an extension cable will also act as antenna for HF signals.

BTW, snr and signal strenght from 75% is not bad, right?

I've a perfect reception with 70%, even on 8psk channels.

Rob Rob wrote:

If you are getting improved results by isolating the card in any way, then the problem is that you had a rubbish signal to start with, bad wiring, alignment issue, dodgy LNB, bad skew. In the situation where your input signal is very weak to start with, then yes of course isolating it may help some amount, but you'd be much better off just getting your dish related hardware and bits sorted, because THAT is your problem.

Are you joking !? I have exactly the same problem with CC errors. It has nothing to do with adjustment of dish, LNB *) etc. The TBS6985 works perfect with an old Asus motherboard with onboard graphic circuits. Another, newer Asus board gives CC errors for mostly HD channels. In this case there is an PCI graphic card. I also suspect some interference issues (RF or DC ripple) but have not tested so much due to lack of time...Or some issues with timing on the PCI bus ?

*)If you use LNB quad, the isolation can be bad so "scanning" one output can cause glitches on another output. In my case I have only used one cable when doing the tests...

I use TBS original driver and also done the MSI interrupt change without any improvements...

Running an old version of Tvh, 3.2.18