Error with CRC in tables (ie. PAT table)

[masjerang]

I believe this is a descrambler issue, but could also be dvbloopback.
CRC of certain tables is failing using descrambler/dvbloopback, doing a channel-scan using dvbv5-scan.
In the example it below, it fails with 'table ID 0x00, program ID 0x00', but it fails also with other tables.

• Can someone confirm this behavior?
• Can someone explain the rewriting of the tables done by descrambler?

See response of virtual adapter:

user@hostname:~$ dvbv5-scan -v -a 2 -d 0 -f 0 /home/user/initial.conf -o dvb_channels.conf
WARNING  Ignoring device /dev/dvb/adapter2/osd0
WARNING  Ignoring device /dev/dvb/adapter2/osd1
WARNING  Ignoring device /dev/dvb/adapter3/osd0
WARNING  Ignoring device /dev/dvb/adapter3/osd1
using demux 'dvb2.demux0'
WARNING  Detected dvbloopback
Device ST STV0367 DDB DVB-C/T (/dev/dvb/adapter2/frontend0) capabilities:
     CAN_FEC_1_2
     CAN_FEC_2_3
     CAN_FEC_3_4
     CAN_FEC_5_6
     CAN_FEC_7_8
     CAN_FEC_AUTO
     CAN_INVERSION_AUTO
     CAN_MUTE_TS
     CAN_QAM_16
     CAN_QAM_32
     CAN_QAM_64
     CAN_QAM_128
     CAN_QAM_256
     CAN_QPSK
     CAN_RECOVER
     CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.11, Current v5 delivery system: DVBC/ANNEX_A
Supported delivery systems: 
    [DVBC/ANNEX_A]
     DVBT
Frequency range for the current standard: 
From:            48.0 MHz
To:               864 MHz
Step:             167 kHz
Symbol rate ranges for the current standard: 
From:             870 kBauds
To:              11.7 MBauds
Failed to guess country from the current locale setting.

ERROR    command BANDWIDTH_HZ (5) not found during retrieve
Cannot calc frequency shift. Either bandwidth/symbol-rate is unavailable (yet).
Scanning frequency #1 474000000
FREQUENCY = 474000000
MODULATION = QAM/64
INVERSION = AUTO
SYMBOL_RATE = 6875000
INNER_FEC = NONE
DELIVERY_SYSTEM = DVBC/ANNEX_A
Got parameters for DVBC/ANNEX_A:
FREQUENCY = 1
MODULATION = QAM/64
INVERSION = AUTO
SYMBOL_RATE = 6874921
INNER_FEC = NONE
DELIVERY_SYSTEM = DVBC/ANNEX_A
Lock   (0x1f) Signal= -22.00dBm C/N= 34.68dB UCB= 11
dvb_read_sections: waiting for table ID 0x00, program ID 0x00
ERROR    dvb_read_sections: crc error
ERROR    error while waiting for PAT table
Scanning frequency #2 164000000
FREQUENCY = 164000000
MODULATION = QAM/64
INVERSION = AUTO
SYMBOL_RATE = 6900000
INNER_FEC = NONE
DELIVERY_SYSTEM = DVBC/ANNEX_A
RF     (0x01) Signal= -22.00dBm

See response of physical adapter:

user@hostname:~$ dvbv5-scan -v -a 1 -d 0 -f 0 /home/user/initial.conf -o dvb_channels.conf
WARNING  Ignoring device /dev/dvb/adapter2/osd0
WARNING  Ignoring device /dev/dvb/adapter2/osd1
WARNING  Ignoring device /dev/dvb/adapter3/osd0
WARNING  Ignoring device /dev/dvb/adapter3/osd1
using demux 'dvb1.demux0'
Device ST STV0367 DDB DVB-C/T (/dev/dvb/adapter1/frontend0) capabilities:
     CAN_FEC_1_2
     CAN_FEC_2_3
     CAN_FEC_3_4
     CAN_FEC_5_6
     CAN_FEC_7_8
     CAN_FEC_AUTO
     CAN_INVERSION_AUTO
     CAN_MUTE_TS
     CAN_QAM_16
     CAN_QAM_32
     CAN_QAM_64
     CAN_QAM_128
     CAN_QAM_256
     CAN_QPSK
     CAN_RECOVER
     CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.11, Current v5 delivery system: DVBC/ANNEX_A
Supported delivery systems: 
    [DVBC/ANNEX_A]
     DVBT
Frequency range for the current standard: 
From:            48.0 MHz
To:               864 MHz
Step:             167 kHz
Symbol rate ranges for the current standard: 
From:             870 kBauds
To:              11.7 MBauds
Failed to guess country from the current locale setting.

ERROR    command BANDWIDTH_HZ (5) not found during retrieve
Cannot calc frequency shift. Either bandwidth/symbol-rate is unavailable (yet).
Scanning frequency #1 474000000
FREQUENCY = 474000000
MODULATION = QAM/64
INVERSION = AUTO
SYMBOL_RATE = 6875000
INNER_FEC = NONE
DELIVERY_SYSTEM = DVBC/ANNEX_A
       (0x00) Signal= -22.00dBm C/N= 37.19dB UCB= 11
Got parameters for DVBC/ANNEX_A:
FREQUENCY = 1
MODULATION = QAM/64
INVERSION = AUTO
SYMBOL_RATE = 6875142
INNER_FEC = NONE
Lock   (0x1f) Signal= -58.00dBm C/N= 34.91dB UCB= 11
dvb_read_sections: waiting for table ID 0x00, program ID 0x00
dvb_parse_section: received table 0x00, extension ID 0x0012, section 0/0
dvb_parse_section: table 0x00, extension ID 0x0012: done
PAT
| table_id         0x00
| section_length      157
| one                 3
| zero                0
| syntax              1
| transport_stream_id 18
| current_next        1
| version             23
| one2                3
| section_number      0
| last_section_number 0
|\ 37 program pids
|  pid 0x0010: service 0x0000
|  pid 0x00c8: service 0x4539
|  pid 0x00ca: service 0x453a
|  pid 0x00cc: service 0x453b
|  pid 0x00ce: service 0x453c
|  pid 0x00d0: service 0x453d
|  pid 0x00d2: service 0x453e
|  pid 0x00d4: service 0x453f
|  pid 0x00d8: service 0x4541
|  pid 0x00da: service 0x4542
|  pid 0x00dc: service 0x4543
|  pid 0x00de: service 0x4544
|  pid 0x00e0: service 0x4545
|  pid 0x00e2: service 0x4546
|  pid 0x00e4: service 0x4547
|  pid 0x00e6: service 0x4548
|  pid 0x00e8: service 0x4549
|  pid 0x00ea: service 0x454a
|  pid 0x00ec: service 0x454b
|  pid 0x00ee: service 0x454c
|  pid 0x00f0: service 0x454d
|  pid 0x00f2: service 0x454e
|  pid 0x00f4: service 0x454f
|  pid 0x00f6: service 0x4550
|  pid 0x00f8: service 0x4551
|  pid 0x00fa: service 0x4552
|  pid 0x00fc: service 0x4553
|  pid 0x00fe: service 0x4554
|  pid 0x0100: service 0x4555
|  pid 0x0102: service 0x4556
|  pid 0x0104: service 0x4557
|  pid 0x0106: service 0x4558
|  pid 0x0108: service 0x4559
|  pid 0x010a: service 0x4560
|  pid 0x1130: service 0x4d25
|  pid 0x0ed8: service 0x4d2b
|  pid 0x0c80: service 0x4d2c
Program #0 is network PID: 0x0010

< break >

[Strunzdesign]

Hi,

the warning message "WARNING Detected dvbloopback" got my interest. I had a quick look into the source code and found this interesting comment:

https://git.linuxtv.org/v4l-utils.git/tree/lib/libdvbv5/dvb-dev-local.c#n453

So it seems that the developers are aware that dvbloopback is (was?!) broken at some point in time ("in recent kernels"). Maybe there are some fundamental issues with dvbloopback, or dvbloopback is no longer broken but a check for dvbloopback stops it from being used as intended.

Regards,
Florian

[masjerang]

Hi Florian,

There a couple of references to dvbloopback. I believe the FE_GET_FRONTEND issue they mention should be fixed now. Let me play around with this libdvbv5 and see if things still work without the special dvbloopback conditions/clauses.
Not sure if it is related to the CRC mismatch, but again something interesting to find out.
Thanks!

[masjerang]

Just a quick comment: I've removed the dvbloopback specifics out of libdvbv5 and nothing changes. 'dvbv5-scan' gives the same results, including CRC error. Even by bypassing the CRC check, the scan does not report any proper channels.conf, while doing this on the physical adapter works perfectly.
Using the 'scan' utility on the dvbloopback adapter does give good results.