Let me add a few more details.
This is the patch I apply to the A867 driver:
diff --git a/drivers/media/dvb/dvb-usb/a867_af903x-fe.c b/drivers/media/dvb/dvb-usb/a867_af903x-fe.c
index 65a498d..a9ed3bf 100644
--- a/drivers/media/dvb/dvb-usb/a867_af903x-fe.c
+++ b/drivers/media/dvb/dvb-usb/a867_af903x-fe.c
@@ -335,6 +335,23 @@ static int af903x_set_frontend(struct dvb_frontend* fe,
return -EINVAL;
}
+#if 1
+ printk(KERN_INFO "- %s: frequency %d Hz\n",__FUNCTION__, fep->frequency);
+ printk(KERN_INFO "- original bw value: %d\n", fep->u.ofdm.bandwidth);
+ printk(KERN_INFO "- original inversion value: %d expected %d\n", fep->inversion, INVERSION_AUTO);
+ printk(KERN_INFO "- original code_rate_HP value: %d expected %d\n", fep->u.ofdm.code_rate_HP, FEC_AUTO);
+ printk(KERN_INFO "- original code_rate_LP value: %d expected %d\n", fep->u.ofdm.code_rate_LP, FEC_AUTO);
+ printk(KERN_INFO "- original constellation value: %d expected %d\n", fep->u.ofdm.constellation, QAM_AUTO);
+ printk(KERN_INFO "- original transmission_mode value: %d expected %d\n", fep->u.ofdm.transmission_mode, TRANSMISSION_MODE_AUTO);
+ printk(KERN_INFO "- original guard_interval value: %d expected %d\n", fep->u.ofdm.guard_interval, GUARD_INTERVAL_AUTO);
+ printk(KERN_INFO "- original hierarchy_information value: %d expected %d\n", fep->u.ofdm.hierarchy_information, HIERARCHY_AUTO);
+ /* dirty hack to set OFDM bandwidth to 7MHz in VHF band */
+ if( fep->frequency <= 230000000 && fep->u.ofdm.bandwidth != BANDWIDTH_7_MHZ ) {
+ printk(KERN_INFO "- %s original bw value: %d overridden to %d\n",__FUNCTION__, fep->u.ofdm.bandwidth, BANDWIDTH_7_MHZ);
+ fep->u.ofdm.bandwidth = BANDWIDTH_7_MHZ;
+ }
+#endif
+
switch(fep->u.ofdm.bandwidth) {
case BANDWIDTH_8_MHZ: bw=8; break;
case BANDWIDTH_7_MHZ: bw=7; break;
--
1.7.0.4
I added a few printk to log some dvb_frontend_parameters.
When I select a VHF channel (MUX RAI VHF Ch 5) I get:
- af903x_set_frontend: frequency 177500000 Hz
- original bw value: 0
- original inversion value: 2 expected 2
- original code_rate_HP value: 0 expected 9
- original code_rate_LP value: 9 expected 9
- original constellation value: 6 expected 6
- original transmission_mode value: 2 expected 2
- original guard_interval value: 4 expected 4
- original hierarchy_information value: 4 expected 4
- af903x_set_frontend original bw value: 0 overridden to 1
while when I select a UHF channel (MUX Mediaset UHF Ch 49) I get:
- af903x_set_frontend: frequency 698000000 Hz
- original bw value: 0
- original inversion value: 2 expected 2
- original code_rate_HP value: 0 expected 9
- original code_rate_LP value: 9 expected 9
- original constellation value: 6 expected 6
- original transmission_mode value: 2 expected 2
- original guard_interval value: 4 expected 4
- original hierarchy_information value: 4 expected 4
The "expected" values are just the "auto" settings.
Basically, the OFDM
bandwidth is always set to 0 (which means 8 MHz), as well as the
code_rate_HP (in this case 0 means FEC is disabled).
Some DVB drivers are using just the frequency and the bandwidth to tune the channel. Examples are the A867 driver, the af9035, the WinTV Nova driver, the A835. Those drivers works on ET9000, but they can only tune UHF channels, while they can not tune any VHF channel with 7MHz bandwidth.
Other drivers are using all the DVB frontend parameters to tune the channel, and they can not work on ET9000 hardware, since the
code_rate_HP parameter is always forced to 0, so FEC is disabled. Those drivers are loading properly, but they can not tune any channel, regardless of what you put in the terrestrial.xml or in the manual scan parameters. Examples are the em28xx-dvb drivers (I tested the PCTV 290e and the Terratec Cinergy Hybrid).
Those problems are specific of ET9000, and maybe also of ET5000. Unfortunately the only user with an ET5000 on SifTeam forum reported that his A867 and A835 sticks are working fine, but he never specifically stated that he was also able to tune VHF channels, so we need more input before ruling the ET5000 out of the equation.
Other boxes (like VU+ DUO) are not affected by the problem, so Enigma2 is probably not the cause of the problem, since the code is the same for all boxes (correct me if I'm wrong).
Nor the DVB API version neither the Linux kernel version can be the origin of the problem, since it is present in all images and all kernel versions (I reproduced it on 2.6.18, 2.6.31 and now on 3.0.3).
So the only probable cause of the problem that I can see are the closed source ET9000 drivers.
By the way, you don't need a VHF channel to reproduce the bug: you only need a working DVB-T stick and a single UHF frequency with channels. Open the manual scan interface and set the frequency of your channel and the bandwidth to 8MHz, leaving all other options on auto. The manual scan will give all the channel in the mux with this configuratio. Now set the bandwidth to 7 MHz or 6 MHz and repeat the scan. You will get all the channels regardeless of the bandwidth parameter, since it is always forced to 0. If the bug was not present you would get no channel with BW set to 7 or 6 MHz.
Edited by Gennar1, 23 October 2011 - 14:24.
