Bug #4535
TBS 6991SE DVBS/S2 card won't work after upgrade to Tvheadend 4.2.3-20~g407c8a3, but it used to work under 4.0.9.
0%
Description
I upgraded Tvheadend to 4.2.3-20~g407c8a3 today and now my TBS 6991SE DVB-S/S2 tuner card simply will not receive anything. Note that although the card has a CA slot, I am not using it since there is no programming that uses that type of conditional access in this part of the world. I have been using it for straight free-to-air reception on North American satellites prior to today's upgrade. I have other TBS cards in this system that do not have a CA slot; they worked under 4.0.9 and continue to work after the upgrade - it is only the TBS 6991SE that fails to work under the new Tvheadend version. My suspicion, although I could be totally off-base on this, is that Tvheadend is detecting that the card has a CA slot and even though it is disabled (it shows "ca0: disabled" under both tuners in the TV adapters tab), perhaps Tvheadend is looking for a decoder that doesn't exist or something? I'm sure it's not common for someone to have a TBS 6991SE and not use the CA slot, but that is the case here and I think that maybe 4.0 didn't look for such a slot and treated the card normally, whereas the new version sees that it has a CA slot and doesn't quite accept the fact that it's not being used for CA programming. When I try to tune in a signal on this card all it does is throw a bunch of continuity errors, whereas it worked fine under 4.0.9. This is the case on both inputs of the card, which are connected to completely separate C-band LNB's on separate dishes, both of which worked prior to the upgrade.
Files
History
Updated by saen acro about 7 years ago
Updated by Do you upgrade and kernel also?
post result of
dmesg | grep frontend tree /sys/class/dvb or tree /dev/dvb
Updated by K Shea about 7 years ago
Updated by These are the parts showing the TBS 6991SE card:
dmesg | grep frontend:
[ 28.537921] DVB: registering adapter 4 frontend 0 (TurboSight TBS 6991SE DVBS/S2 frontend)...
[ 28.933849] DVB: registering adapter 5 frontend 0 (TurboSight TBS 6991SE DVBS/S2 frontend)...
tree /sys/class/dvb:
├── dvb4.ca0 -> ../../devices/pci0000:00/0000:00:1c.0/0000:02:00.0/dvb/dvb4.ca0
├── dvb4.demux0 -> ../../devices/pci0000:00/0000:00:1c.0/0000:02:00.0/dvb/dvb4.demux0
├── dvb4.dvr0 -> ../../devices/pci0000:00/0000:00:1c.0/0000:02:00.0/dvb/dvb4.dvr0
├── dvb4.frontend0 -> ../../devices/pci0000:00/0000:00:1c.0/0000:02:00.0/dvb/dvb4.frontend0
├── dvb4.net0 -> ../../devices/pci0000:00/0000:00:1c.0/0000:02:00.0/dvb/dvb4.net0
├── dvb5.ca0 -> ../../devices/pci0000:00/0000:00:1c.0/0000:02:00.0/dvb/dvb5.ca0
├── dvb5.demux0 -> ../../devices/pci0000:00/0000:00:1c.0/0000:02:00.0/dvb/dvb5.demux0
├── dvb5.dvr0 -> ../../devices/pci0000:00/0000:00:1c.0/0000:02:00.0/dvb/dvb5.dvr0
├── dvb5.frontend0 -> ../../devices/pci0000:00/0000:00:1c.0/0000:02:00.0/dvb/dvb5.frontend0
├── dvb5.net0 -> ../../devices/pci0000:00/0000:00:1c.0/0000:02:00.0/dvb/dvb5.net0
tree /dev/dvb:
├── adapter4
│ ├── ca0
│ ├── demux0
│ ├── dvr0
│ ├── frontend0
│ └── net0
├── adapter5
│ ├── ca0
│ ├── demux0
│ ├── dvr0
│ ├── frontend0
│ └── net0
Updated by saen acro about 7 years ago
Existing of PCMCIA CA slot on card is noting to do with tuners on card.
Updated by K Shea about 7 years ago
Well...
I tried creating a new DVB-S test network and assigning it to one of the tuners on the 6991SE card, and then created and scanned a known good mux:
2017-08-19 12:32:06.936 mpegts: 4020V in Test - tuning on TurboSight TBS 6991SE DVBS/S2 frontend : DVB-S #0:B 2017-08-19 12:32:06.938 subscription: 001D: "scan" subscribing to mux "4020V", weight: 6, adapter: "TurboSight TBS 6991SE DVBS/S2 frontend : DVB-S #0:B", network: "Test", service: "Raw PID Subscription" 2017-08-19 12:32:08.322 tbl-base: nit: 4020V in Test: invalid checksum (len 115, errors 1) 2017-08-19 12:32:09.839 mpegts: 4020V in Test scan complete 2017-08-19 12:32:09.839 subscription: 001D: "scan" unsubscribing 2017-08-19 12:33:54.771 service-mapper: Test/4020V/CHANNEL-1: success
It actually did find all the services on the mux, but displayed that one error ("tbl-base: nit: 4020V in Test: invalid checksum (len 115, errors 1)").
I then mapped a known good service to a channel. It was only when trying to play the channel that everything fell apart:
2017-08-19 12:34:30.561 htsp: Got connection from 192.168.1.24 2017-08-19 12:34:30.566 htsp: 192.168.1.24: Welcomed client software: Kodi Media Center (HTSPv25) 2017-08-19 12:34:30.576 htsp: 192.168.1.24 [ Kodi Media Center ]: Identified as user 'hts' 2017-08-19 12:34:47.201 mpegts: 4020V in Test - tuning on TurboSight TBS 6991SE DVBS/S2 frontend : DVB-S #0:B 2017-08-19 12:34:47.202 subscription: 001E: "192.168.1.24 [ hts | Kodi Media Center ]" subscribing on channel "CHANNEL-1", weight: 150, adapter: "TurboSight TBS 6991SE DVBS/S2 frontend : DVB-S #0:B", network: "Test", mux: "4020V", provider: "Acme", service: "CHANNEL-1", profile="htsp", hostname="192.168.1.24", username="hts", client="Kodi Media Center" 2017-08-19 12:34:48.210 TS: Test/4020V/CHANNEL-1: H264 @ #1281 Continuity counter error (total 1) 2017-08-19 12:34:48.232 TS: Test/4020V/CHANNEL-1: AC3 @ #1282 Continuity counter error (total 1) 2017-08-19 12:34:48.247 TS: Test/4020V/CHANNEL-1: AC3 @ #1284 Continuity counter error (total 1) 2017-08-19 12:34:48.262 TS: Test/4020V/CHANNEL-1: AC3 @ #1283 Continuity counter error (total 1) 2017-08-19 12:34:48.781 tbl-base: sdt: 4020V in Test: invalid checksum (len 352, errors 1) 2017-08-19 12:34:50.231 tbl-base: nit: 4020V in Test: invalid checksum (len 115, errors 1) 2017-08-19 12:34:58.216 TS: Test/4020V/CHANNEL-1: H264 @ #1281 Continuity counter error (total 5235) 2017-08-19 12:34:58.239 TS: Test/4020V/CHANNEL-1: AC3 @ #1282 Continuity counter error (total 409) 2017-08-19 12:34:58.261 TS: Test/4020V/CHANNEL-1: AC3 @ #1284 Continuity counter error (total 231) 2017-08-19 12:34:58.291 TS: Test/4020V/CHANNEL-1: AC3 @ #1283 Continuity counter error (total 222) 2017-08-19 12:35:04.031 tbl-base: sdt: 4020V in Test: invalid checksum (len 352, errors 2) 2017-08-19 12:35:08.223 TS: Test/4020V/CHANNEL-1: H264 @ #1281 Continuity counter error (total 10062) 2017-08-19 12:35:08.268 TS: Test/4020V/CHANNEL-1: AC3 @ #1282 Continuity counter error (total 807) 2017-08-19 12:35:08.268 TS: Test/4020V/CHANNEL-1: AC3 @ #1283 Continuity counter error (total 434) 2017-08-19 12:35:08.268 TS: Test/4020V/CHANNEL-1: AC3 @ #1284 Continuity counter error (total 451) 2017-08-19 12:35:08.351 tbl-base: cat: 4020V in Test: invalid checksum (len 30, errors 1) 2017-08-19 12:35:08.817 tbl-base: pat: 4020V in Test: invalid checksum (len 64, errors 1) 2017-08-19 12:35:14.902 tbl-base: pmt: 4020V in Test: invalid checksum (len 90, errors 1) 2017-08-19 12:35:17.253 subscription: 001E: "192.168.1.24 [ hts | Kodi Media Center ]" unsubscribing from "CHANNEL-1", hostname="192.168.1.24", username="hts", client="Kodi Media Center" 2017-08-19 12:35:30.703 htsp: 192.168.1.24 [ hts | Kodi Media Center ]: Disconnected
Again this did NOT happen under 4.0. Tvheadend had no problems playing this channel until I upgraded to 4.2. Coincidentally, additional support for CA cards was added in 4.2. Coincidentally, every TBS card I have tried that does NOT have a CA slot works perfectly in 4.2. Is it possible that when adding support for CA cards in 4.2, the condition where a card is in use that has CA slots, but where nothing is plugged into the CA slots, wasn't tested properly? Otherwise, there are a lot of strange coincidences here, and I'm finding it difficult to believe they aren't in some way related. In any case, even if the CA slot has nothing to do with it, there's still a problem, because a card that worked great under 4.0 now doesn't work under 4.2.
@saen acro, just so I know who I am talking to, are you an actual Tvheadend developer? And if so, did you personally work on the code that added support for CA slots in 4.2?
Updated by Mark Clarkstone about 7 years ago
Updated by K Shea wrote:
.. snip ..
Using 4.0, can you wget a full mux and upload a sample here? (max 100mb due to cloudflare).
Updated by K Shea about 7 years ago
Also, I have no idea if this thread is in any way related to this problem, but since there is a slim chance it might be I'll post the link: https://tvheadend.org/boards/13/topics/26397
Updated by K Shea about 7 years ago
Mark Clarkstone wrote:
Using 4.0, can you wget a full mux and upload a sample here? (max 100mb due to cloudflare).
Unfortunately I don't have 4.0 installed on that backend right now, I possibly could reinstall it from a backup but that would be a major PITA, and also I don't know what you mean by "wget a full mux" - the only usage of wget I am aware of is to get a file from a web server. So even if I had 4.0 readily available, I'm not certain what you are asking me to do.
Updated by Jaroslav Kysela about 7 years ago
Updated by 
Did you change the kernel / TBS driver, too ? Almost all TBS problems are caused by the driver. The CA code should not touch the incoming stream when deactivated (Enabled field is unchecked in the device tree in CA configs).
Updated by K Shea about 7 years ago
If you mean the Linux kernel, that is the same (4.4.0-92-generic). As for the TBS driver, I did initially try installing the new open source driver using the installation instructions at https://github.com/tbsdtv/linux_media/wiki but when this issue appeared, one of the first things I tried was going back to the original TBS drivers that I have been using prior to the upgrade. In both cases it appeared the other TBS cards worked, and only the 6991SE failed to work. And in case you are wondering, I did remove all the open source drivers from /kernel/drivers/media before going back to the original proprietary TBS drivers that I've been using.
The enabled field is unchecked in the device tree in CA configs; see attached screenshot.
Updated by Jaroslav Kysela about 7 years ago
No further idea. But if some cards works, then it appears that the issue is outside tvheadend. The CA device is not touched by tvheadend when not enabled. You can also compile tvh without dvben50221 (CA) '--disable-dvben50221' option for configure.