Continuity counter errors - VERY interesting discovery for my CC problems - only every 2nd tuner of my 8 tuners causes this?!

Crazy Fin

Hi all

I have been struggling back and forth with the infamous continuity errors for a year.

On some versions it has been very good with no CC errors at all (except during very heavy thunderstorms which must be seen as normal).

Latest unstable 3.9.1353 (precise-amd64) has been very stable and I am very happy with this release.

I am running on Ubuntu 12.04 LTS updated with all the latest patches.

The TV server I am running TVH on is Intel Quad Core I3-2120 @ 3.30GHz with 16 GB RAM.

The tuner cards are 2 PCIe cards from Digital Devices, the Cine S2 cards with 2 tuners originally on the card but I have added the option DuoFlex S2 which expands each card to 4 tuners each, i.e. I have totally 8 tuners connected to my satellite dish that has an octo LNB.

(Tuner card info: http://www.digitaldevices.de/english/DDD-Images/Cine_S2_engl_02-2013.pdf)

I have measured the signal and quality strength at the connector end that is connected to the tuner cards. I have measured with a SatLink WS-6926 (http://www.satlink.de/satlink-ws-6926-hd-second-edition.html) and all 8 cables are showing anywhere from 75 to 85% signal strenght as well as 72 to 82% signal quality. So no problem with the signal coming into my tuner cards.

I am using the drivers found at http://linuxtv.org/hg/~endriss/media_build_experimental/ and I have followed the instruction at

http://shop.digital-devices.de/epages/62357162.sf/?ObjectPath=/Shops/62357162/Categories/DownloadsNew1/Linux_Unterstuetzung_fuer_Digital_Devices_Produkte

Initially I suspected that the reason for my CC errors/problems were to one or two defective tuners on one of the tuner cards since I always got CC errors on Tuner 2 and 4 but after more testing and research I discovered the following VERY strange pattern:

If I have ALL 8 tuners enabled in TVH configuration I always get CC errors (for HD channels only!) if TVH uses ANY of the seconday tuners?! So on the first Cine S2 the 2nd tuner creates CC errors and on the 2nd tuner on the DuoFlex S2 card (the addon card on the first main card).

Same thing on my 2nd main card Cine S2 and the DuoFlex S2 addon card to that.

If I disable every 2nd tuner in TVH it all works fine without any CC errors at all even if I use all 4 enabled tuners at the same time. This is very strange!

Ok so I removed the 2nd main card (Cine S2) plus its mounted add on card DuoFlex S2 and only have one tuner card with 4 tuners (Cine S2 + DuoFlex S2) installed.
Result? CC errors as soon as I start using all 4 tuners and the tuners causing the CC errors is the 2nd tuner on the main Cine S2 card and the 2nd tuner on the DuoFlex S2 add on card. Definately a strange pattern here!

As soon as I disable the 2nd tuner on the main Cine S2 card and the 2nd tuner on the DuoFlex S2 add on card and only utilize the 2 remaining "main/primary" tuners on each card it works fine again without any CC errors at all.

I even tried with removing the add on cards DuoFlex S2 from the main boards and only used the Cine S2 card with 2 tuners but same problem again if I enable both tuners. CC errors as soon as TVH starts to use the 2nd tuner.

Same thing if I remove the DuoFlex S2 from my 2nd main card Cine S2 and mount 2 of the Cine S2 cards into my computer, i.e. 4 tuners in total but without the DuoFlex S2 cards.

CC errors again on every 2nd tuner and as soon as I disable them the remaining 2 tuners out of 4 works fine without any CC errors.

So I have now mounted back everything into my computer and I have now 8 tuners in my computer but I have disabled 4 of them (every 2nd tuner or if you want to call it the secondary tuner) and it all works fine without any CC errors at all even if I use all 4 tuners at the same time for recording and/or live TV watching.

However, it feels very sad to be able to only utilize 50% of my tuner "park".

I have contacted Digital Devices with my findings but (as expected) no response at all.

I am keen on testing the TBS6985 DVB S2 quad tuner card to see if I would get the same problems but when I searched through the TBS forums I found a guy that had IDENTICAL issues as me with every 2nd tuner causing CC errors on HD channels:

http://www.tbsdtv.com/forum/viewtopic.php?f=142&t=8868

And another very interesting thread were similar issues are discussed:

http://www.tbsdtv.com/forum/viewtopic.php?f=37&t=8278#p28202 (however, in this thread they are discussing the TBS6984-card but TBS is commenting in that thread about replacing the 6984-card with a 6985-card due to totally different construction on the newer card)

Looks like it is boiling down to some kind of PCIe latency issues causing packets being lost?

@Adam Sutton, may I ask you if you currently are using the TBS6985 card and are you using the original drivers from TBS or the alternative driver from Luis?

Have you tested to utilize all 4 tuners at the same time and for HD channels on all 4 tuners to see if you get any CC errors?

Alfred Zastrow

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

Crazy Fin

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...

Rob vh

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).

glenn ch

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.

Rob Rob

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.

Crazy Fin

@Rob 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 ch: may I ask how you did the isolation of the F-connectors on the tuner cards?

@Rob 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?

Alfred Zastrow

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

glenn ch

@Rob 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 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 onthe 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!

Crazy Fin

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: AttachingSTV6110x [ 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?

glenn ch

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)

Crazy Fin

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.
<<

Rob vh

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.

Crazy Fin

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."

Crazy Fin

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.

Crazy Fin

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...

Rob vh

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.

glenn ch

@Crazy 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..

Crazy Fin

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. :-)

Crazy Fin

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.