Bug 202083

Summary:	DVB: budget_ci: frequency out of range (470000000..862000000)
Product:	v4l-dvb	Reporter:	jp31337
Component:	ttpci	Assignee:	drivers_other
Status:	NEW ---
Severity:	blocking	CC:	ari.kohtamaki, jp31337, kramski
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	4.19.10-200.fc28.x86_64	Subsystem:
Regression:	Yes	Bisected commit-id:

Description jp31337 2018-12-28 08:07:04 UTC

I have a Technotrend TT Budget C 1500:
dvbdev: DVB: registering new adapter (TT-Budget-C-CI PCI)

I'm using mythtv for TV recordings.

With kernel 4.18.19-100.fc27.x86_64 it works fine (has worked fine for last ~10 years).

When I boot into kernel 4.19.10-200.fc28.x86_64, the recording fails and I get this message:
kernel: budget_ci dvb 0000:04:02.0: DVB: adapter 1 frontend 0 frequency 362000000 out of range (470000000..862000000)

362000000 is the correct frequency! For some reason, the 4.19 kernel has frequency locked to 470000000..862000000. Most TV channels in Finnish TV network are below that frequency.

Example from channels.conf:
Yle TV1 HD;YLE:362000:M256:C:6900:310=27:0;850,853:5000;1127:0:1501:0:31:0:210
Yle TV1;YLE:162000:M128:C:6900:512=2:650=fin@3:5000;1027,1050:0:17:15:3:0:6300
Yle TV2 HD;YLE:362000:M256:C:6900:312=27:0;860:5001;2127,2128:0:1502:0:31:0:212
Yle TV2;YLE:162000:M128:C:6900:513=2:660=fin@3:2700;2027,2050:0:33:15:3:0:6301

Comment 1 kramski 2019-03-10 11:51:51 UTC

My Technotrend C-1500 DVB-C card also suffers from this issue, which breaks tuning and scanning in MythTV and TVheadend for me.

On Arch Linux, kernel 5.0 and even 4.19.27 LTS are affected. My current, temporary workaround was to downgrade to 4.18.16.

An easy method to reproduce is to run a blind scan with "w_scan -fc -c DE -Q 1"

On 4.18 this gives:

w_scan version 20170107 (compiled for DVB API 5.11)
using settings for GERMANY
DVB cable
DVB-C
scan type CABLE, channellist 7
output format vdr-2.0
WARNING: could not guess your codepage. Falling back to 'UTF-8'
output charset 'UTF-8', use -C <charset> to override
Info: using DVB adapter auto detection.
    /dev/dvb/adapter0/frontend0 -> CABLE "ST STV0297 DVB-C": good :-)
Using CABLE frontend (adapter /dev/dvb/adapter0/frontend0)
-_-_-_-_ Getting frontend capabilities-_-_-_-_ 
Using DVB API 5.11
frontend 'ST STV0297 DVB-C' supports
INVERSION_AUTO
QAM_AUTO not supported, trying QAM_256.
FEC_AUTO
FREQ (47.00MHz ... 862.00MHz)
SRATE (0.870MSym/s ... 11.700MSym/s)
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ 
searching QAM256...
73000: sr6900 (time: 00:00.436) sr6875 (time: 00:02.290) 
81000: sr6900 (time: 00:04.163) sr6875 (time: 00:05.953) 
113000: sr6900 (time: 00:07.740) sr6875 (time: 00:09.756) 
121000: sr6900 (time: 00:11.956) sr6875 (time: 00:14.090) 
[...]


In contrast on 4.19 I get:

w_scan version 20170107 (compiled for DVB API 5.11)
using settings for GERMANY
DVB cable
DVB-C
scan type CABLE, channellist 7
output format vdr-2.0
WARNING: could not guess your codepage. Falling back to 'UTF-8'
output charset 'UTF-8', use -C <charset> to override
Info: using DVB adapter auto detection.
    /dev/dvb/adapter0/frontend0 -> CABLE "ST STV0297 DVB-C": good :-)
Using CABLE frontend (adapter /dev/dvb/adapter0/frontend0)
-_-_-_-_ Getting frontend capabilities-_-_-_-_ 
Using DVB API 5.11
frontend 'ST STV0297 DVB-C' supports
INVERSION_AUTO
QAM_AUTO not supported, trying QAM_256.
FEC_AUTO
FREQ (470.00MHz ... 862.00MHz)
SRATE (0.870MSym/s ... 11.700MSym/s)
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ 
searching QAM256...
73000: sr6900 (time: 00:00.250) 	 skipped: (freq 73000000 unsupported by driver)

initial_tune:2813: Setting frontend failed QAM_256  f = 73000 kHz S6900C999  (0:0:0)
sr6875 (time: 00:00.250) 	 skipped: (freq 73000000 unsupported by driver)

initial_tune:2813: Setting frontend failed QAM_256  f = 73000 kHz S6875C999  (0:0:0)
81000: sr6900 (time: 00:00.250) 	 skipped: (freq 81000000 unsupported by driver)

initial_tune:2813: Setting frontend failed QAM_256  f = 81000 kHz S6900C999  (0:0:0)
sr6875 (time: 00:00.250) 	 skipped: (freq 81000000 unsupported by driver)

initial_tune:2813: Setting frontend failed QAM_256  f = 81000 kHz S6875C999  (0:0:0)
113000: sr6900 (time: 00:00.250) 	 skipped: (freq 113000000 unsupported by driver)

initial_tune:2813: Setting frontend failed QAM_256  f = 113000 kHz S6900C999  (0:0:0)
sr6875 (time: 00:00.250) 	 skipped: (freq 113000000 unsupported by driver)

initial_tune:2813: Setting frontend failed QAM_256  f = 113000 kHz S6875C999  (0:0:0)
121000: sr6900 (time: 00:00.250) 	 skipped: (freq 121000000 unsupported by driver)

initial_tune:2813: Setting frontend failed QAM_256  f = 121000 kHz S6900C999  (0:0:0)
sr6875 (time: 00:00.250) 	 skipped: (freq 121000000 unsupported by driver)


Also note the different frontend capabilities reported: On 4.19, "FREQ (470.00MHz ... 862.00MHz)" is reported, which should be "FREQ (47.00MHz ... 862.00MHz)" like on 4.18. Looks like the lower limit is off by factor of 10. Frontend capabilities can also be printed by "dvb-fe-tool".

Comment 2 kramski 2019-03-10 11:53:35 UTC

I may aadd that I also have a slightly newer TT C-1501 which is not affected.

Comment 3 kramski 2019-05-20 19:23:20 UTC

Tuning the TT C-1500 still fails on Kernels 5.1.3.arch1-1 and 4.19.44-1-lts on Arch.

Comment 4 arikohta 2019-06-23 16:36:55 UTC

Please fix this typo in dvb-frontends/stv0297.c.

--- ./linux-4.18.16/drivers/media/dvb-frontends/stv0297.c       2018-10-20 10:47:10.000000000 +0300
+++ ./linux-4.19.27/drivers/media/dvb-frontends/stv0297.c       2019-03-05 18:58:54.000000000 +0200
@@ -694,9 +694,9 @@
        .delsys = { SYS_DVBC_ANNEX_A },
        .info = {
                 .name = "ST STV0297 DVB-C",
-                .frequency_min = 47000000,
-                .frequency_max = 862000000,
-                .frequency_stepsize = 62500,
+                .frequency_min_hz = 470 * MHz,
+                .frequency_max_hz = 862 * MHz,
+                .frequency_stepsize_hz = 62500,
                 .symbol_rate_min = 870000,
                 .symbol_rate_max = 11700000,
                 .caps = FE_CAN_QAM_16 | FE_CAN_QAM_32 | FE_CAN_QAM_64 |

Ie. frequency_min_hz should say (not 470 Mhz):
+                .frequency_min_hz = 47 * MHz,

Comment 5 arikohta 2019-07-17 17:18:59 UTC

This is now fixed in recent kernels (5.2.1, 5.1.18 and 4.19.59).

Comment 6 kramski 2019-07-21 21:07:16 UTC

Fix confirmed on 5.2.1-arch1-1-ARCH.

Thanks for taking care of this quite old card.

Heinz