(I'll start a new thread as my problem may not be the same as the one posted earlier).
VDR 1.7.15 will not record or show live TV from my DVB-T card - 1.7.14 was fine. On startup I see this message in the log:
Jun 8 16:24:14 vdr: [18819] frontend 0/0 provides DVB-T with unknown modulations ("DST DVB-T")
The problem seems to be in the new code in dvbdevice.c. My card returns frontendInfo.caps = 0xb0201, ie the FE_CAN_QAM_AUTO bit is set but not any of the individual QAM bits. Hence the logic in cDvbDevice::ProvidesTransponder() incorrectly decides that the card cannot receive any channel.
The simple patch (attached) fixes the problem but I'm not sure that it doesn't break something else.
Dave
I'm not sure what FE_CAN_QAM_AUTO is supposed to represent exactly so the problem may not be in VDR, but rather your cards driver not accurately reporting it's capabilities. In which case, the driver needs to be fixed of course.
On Tuesday 08 Jun 2010, VDR User wrote:
I'm not sure what FE_CAN_QAM_AUTO is supposed to represent exactly so the problem may not be in VDR, but rather your cards driver not accurately reporting it's capabilities. In which case, the driver needs to be fixed of course.
The card is a Twinhan DST DVB-T using the bttv driver. I'm not an expert at reading kernel source, but in drivers/media/dvb/bt8xx/dst.c it does seem that FE_CAN_QAM_AUTO is unconditionally set. The card documentation doesn't specify whether the device can in fact handle all possible QAM settings.
Dave
On 09.06.2010 20:13, Dave P wrote:
On Tuesday 08 Jun 2010, VDR User wrote:
I'm not sure what FE_CAN_QAM_AUTO is supposed to represent exactly so the problem may not be in VDR, but rather your cards driver not accurately reporting it's capabilities. In which case, the driver needs to be fixed of course.
The card is a Twinhan DST DVB-T using the bttv driver. I'm not an expert at reading kernel source, but in drivers/media/dvb/bt8xx/dst.c it does seem that FE_CAN_QAM_AUTO is unconditionally set. The card documentation doesn't specify whether the device can in fact handle all possible QAM settings.
My understanding of the FE_CAN_QAM_... flags is that the driver must tell the application which modulations it can handle. If FE_CAN_QAM_AUTO is set, the application doesn't need to tell the driver which modulation to use, because the driver (or better: the device) can detect it automatically. If a driver only sets FE_CAN_QAM_AUTO, the applications can't know which of the various modulations the device can actually handle. I don't think that FE_CAN_QAM_AUTO is a synonym for "can handle *all* modulations".
The simplest fix (if it is unknown which modulations the device can actually handle) is probably to set all FE_CAN_QAM_... flags in the driver.
Your patch is not a solution, only a workaround. It would prevent drivers that can actually handle only a subset of modulations, but do have "auto" capability, from being properly handled by the application.
Klaus
-
Dave P -
Klaus Schmidinger -
VDR User