Project

General

Profile

Bug #5625

Many Continuity errors while using CXD2837ER (Astrometa white stick)

Added by ly chen over 5 years ago. Updated over 4 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2019-05-06
Due date:
% Done:

0%

Estimated time:
Found in version:
Tvheadend 4.2.8-23~g74cdf3f16
Affected Versions:

Description

I'm running Ubuntu 18.04LTS, kernel updated to 5.0.10 to support the 2018 version of Astrometa USB stick.

The problem is, when watching DVB-C streams, I get continuously Continuity counter errors about every 5 secs, even in strong signal muxes.
But if I check the "Force old status" in TV adapters settings, the Continuity errors disappears, but there's no signal strength and SNR in status tab.
Maybe it's not a TVH bug but a kernel driver bug, I'm a linux newbie, I don't know how to check that.

Log is here

2019-05-06 11:11:36.207 dvr: /mnt/ST3T/nfs/炽热阿拉伯(2)-1.ts from adapter: "Sony CXD2837ER DVB-T/T2/C demodulator #0 : DVB-C #1", network: "DVB-C", mux: "363MHz", provider: "BGCTV", service: "CCTV9纪录高清"
2019-05-06 11:11:36.207 dvr: # type lang resolution aspect ratio sample rate channels
2019-05-06 11:11:36.207 dvr: 1 H264 1920x1080 ?
2019-05-06 11:11:36.207 dvr: 2 AC3 eng ? ?
2019-05-06 11:11:36.207 dvr: 3 CA
2019-05-06 11:11:36.207 dvr: 4 CA
2019-05-06 11:11:36.207 dvr: 5 CA
2019-05-06 11:11:36.207 dvr: 6 CA
2019-05-06 11:11:36.476 TS: DVB-C/363MHz/CCTV9纪录高清: H264 #6090 Continuity counter error (total 1)
2019-05-06 11:11:36.476 TS: DVB-C/363MHz/CCTV9纪录高清: AC3
#6091 Continuity counter error (total 1)
2019-05-06 11:12:26.110 TS: DVB-C/363MHz/CCTV9纪录高清: H264 #6090 Continuity counter error (total 3)
2019-05-06 11:12:38.125 TS: DVB-C/363MHz/CCTV9纪录高清: H264
#6090 Continuity counter error (total 13)
2019-05-06 11:12:49.042 TS: DVB-C/363MHz/CCTV9纪录高清: H264 #6090 Continuity counter error (total 20)
2019-05-06 11:12:56.674 TS: DVB-C/363MHz/CCTV9纪录高清: AC3
#6091 Continuity counter error (total 2)
2019-05-06 11:12:59.923 TS: DVB-C/363MHz/CCTV9纪录高清: H264 #6090 Continuity counter error (total 28)
2019-05-06 11:13:09.791 tbl-pass: pass-eit: -: invalid checksum (len 67, errors 1)
2019-05-06 11:13:09.791 tbl-eit: eit: 363MHz in DVB-C: invalid checksum (len 67, errors 1)
2019-05-06 11:13:10.835 TS: DVB-C/363MHz/CCTV9纪录高清: H264
#6090 Continuity counter error (total 34)
2019-05-06 11:13:11.992 TS: DVB-C/363MHz/CCTV9纪录高清: AC3 #6091 Continuity counter error (total 3)
2019-05-06 11:13:22.857 TS: DVB-C/363MHz/CCTV9纪录高清: H264
#6090 Continuity counter error (total 38)


Files

tvheadend_cleanup_stats_code.patch (7.78 KB) tvheadend_cleanup_stats_code.patch Simplify DVBv5 stats code Mauro Carvalho Chehab, 2019-10-06 15:07

History

#1

Updated by Tiago Freire over 5 years ago

ly chen wrote:

I'm running Ubuntu 18.04LTS, kernel updated to 5.0.10 to support the 2018 version of Astrometa USB stick.

The problem is, when watching DVB-C streams, I get continuously Continuity counter errors about every 5 secs, even in strong signal muxes.
But if I check the "Force old status" in TV adapters settings, the Continuity errors disappears, but there's no signal strength and SNR in status tab.
Maybe it's not a TVH bug but a kernel driver bug, I'm a linux newbie, I don't know how to check that.

(...)

The same situation over where, lots of continuity errors and the USB stick freezes after some time running and scrolling the channels.

Tvheadend on a LXC with Ubuntu 18.04, over Proxmox 6.

#3

Updated by Mauro Carvalho Chehab about 5 years ago

After some tests, I'm pretty sure this is not a Kernel bug, but, instead, a problem at tvheadend. On a quick look, the logic to decide to fall back to DVBv3 seems too complex than it should be. If FE_GET_PROPERTY returns a property with len > 0, then the Kernel driver uses DVBv5 to report stats. Calling a DVBv3 stat after that and mixing with the output of the stats property may cause too much I2C traffic at some devices and may cause problems.

So, the logic there should be something like:

/* Check if DVBv5 stats are available */
gotprop = 0;
if(ioctl_check(lfe, 0) && !lfe->lfe_old_status &&
!ioctl(lfe->lfe_fe_fd, FE_GET_PROPERTY, &dtv_prop)) {
for (i = 0; i < dtv_prop.num; i++)
if (fe_properties[i].u.st.len)
break;
if (i < dtv_prop.num)
gotprop = 1;
}
if (gotprop) {
/* Use only DVBv5 stats /
}
else {
/
Use only DVBv3 stats */
}

I'm enclosing an untested patch cleaning up the stats logic to take this into account.

#4

Updated by Jaroslav Kysela about 5 years ago

  • Status changed from New to Fixed

Got it. Fixed in v4.3-1808-g691cce4a7 .

#5

Updated by saen acro about 5 years ago

#6

Updated by Muhannad Shaheen over 4 years ago

can confirm this is still an issue with CXD2837ER (Astrometa white stick)
linux: 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
tvheadend: 4.3-1857~g221c29b40

#7

Updated by Václav Ovsík over 4 years ago

I can confirm the problem too. Astrometa DVB-T2 & HTS Tvheadend 4.3-1857~g221c29b40

root@pi4:~# dmesg |fgrep DVB
[    5.350220] usb 1-1.4: dvb_usb_v2: found a 'Astrometa DVB-T2' in warm state
[    5.555480] dvbdev: DVB: registering new adapter (Astrometa DVB-T2)
[    5.646759] i2c i2c-7: cxd2841er_attach(): attaching CXD2837ER DVB-C/T/T2 frontend
[    5.646808] usb 1-1.4: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
[    5.646843] dvbdev: dvb_create_media_entity: media entity 'Realtek RTL2832 (DVB-T)' registered.
[    5.647128] usb 1-1.4: DVB: registering adapter 0 frontend 1 (Sony CXD2837ER DVB-T/T2/C demodulator)...
[    5.647152] dvbdev: dvb_create_media_entity: media entity 'Sony CXD2837ER DVB-T/T2/C demodulator' registered.
[    5.754656] rc rc0: Astrometa DVB-T2 as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/rc/rc0
[    5.755055] input: Astrometa DVB-T2 as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/rc/rc0/input4
[    5.766091] usb 1-1.4: dvb_usb_v2: 'Astrometa DVB-T2' successfully initialized and connected

on Raspberry Pi4 with RPi kernel:
Linux pi4 5.4.24-v7l+ #1 SMP Wed Mar 18 07:37:31 CET 2020 armv7l GNU/Linux

Seems to me, it is a kernel driver bug. When I run dvbv5-zap with option -m, there are continuity errors too.
zito@pi4:~/dvb-t2 $ timeout 15 dvbv5-zap -f 1 -c channel-618.conf 'CT 2 HD T2' -m &>zap.log
zito@pi4:~/dvb-t2 $ fgrep continuity zap.log | head -10
   17      1.99 p/s    2.920 Kbps       752 B        1 continuity errors
   17      1.33 p/s    1.954 Kbps       752 B        1 continuity errors
 2223     46.57 p/s   68.405 Kbps       26 KB        1 continuity errors
   17      2.00 p/s    2.937 Kbps        1 KB        1 continuity errors
 2223     46.74 p/s   68.647 Kbps       34 KB        1 continuity errors
 2250     11.00 p/s   16.152 Kbps        8 KB        1 continuity errors
 2723     46.49 p/s   68.280 Kbps       34 KB        1 continuity errors
   17      1.59 p/s    2.342 Kbps        1 KB        1 continuity errors
 2223     46.63 p/s   68.491 Kbps       43 KB        1 continuity errors
 2250     13.95 p/s   20.489 Kbps       13 KB        1 continuity errors

...so probably not the bug in Tvheadend.
Thnaks

#8

Updated by Nichita Dumitrescu over 4 years ago

I solved this problem by checking "Force old status" in adapter settings.

I'm using Debian 10 with updated kernel to 5.4.0-0.bpo.4-amd64.
tvheadend: version 4.3-1857~g221c29b40.
tuner: Astrometa with Sony CXD2837ER

I hope this helps.

Also available in: Atom PDF