VDR-1.7.16 doesn't respect valid dvb device frequency ranges

Message ID 1290873552.18375.21.camel@pluto
State New
Headers

Commit Message

Andreas Brachold Nov. 27, 2010, 3:59 p.m. UTC
  Hello,

Any current vdr doesn't respect valid dvb device frequency ranges.
Here on a EPG-Scan it's generate many messages on syslog, like :

DVB: adapter 0 frontend 0 frequency 177500000 out of range
(470000000..860000000)
DVB: adapter 0 frontend 0 frequency 177500000 out of range
(470000000..860000000)
DVB: adapter 0 frontend 0 frequency 177500000 out of range
(470000000..860000000)


Any of my three DVB-T devices have different frequency ranges,
and the primary device can't receive VHF-channels.

frontend 0:0 frequency range 470000000..860000000
frontend 1:0 frequency range  51000000..858000000
frontend 2:0 frequency range 177000000..858000000


Therefore i attach a simple patch to check provided frequency ranges of
used dvb-t device driver.

Andreas
  

Comments

Klaus Schmidinger March 3, 2012, 12:45 p.m. UTC | #1
On 27.11.2010 16:59, Andreas Brachold wrote:
> Hello,
>
> Any current vdr doesn't respect valid dvb device frequency ranges.
> Here on a EPG-Scan it's generate many messages on syslog, like :
>
> DVB: adapter 0 frontend 0 frequency 177500000 out of range
> (470000000..860000000)
> DVB: adapter 0 frontend 0 frequency 177500000 out of range
> (470000000..860000000)
> DVB: adapter 0 frontend 0 frequency 177500000 out of range
> (470000000..860000000)
>
>
> Any of my three DVB-T devices have different frequency ranges,
> and the primary device can't receive VHF-channels.
>
> frontend 0:0 frequency range 470000000..860000000
> frontend 1:0 frequency range  51000000..858000000
> frontend 2:0 frequency range 177000000..858000000
>
>
> Therefore i attach a simple patch to check provided frequency ranges of
> used dvb-t device driver.
>
> --- dvbdevice.c.orig	2010-05-01 11:47:13.000000000 +0200
> +++ dvbdevice.c	2010-11-27 16:53:43.000000000 +0100
> @@ -911,6 +911,14 @@
>  {
>    if (!ProvidesSource(Channel->Source()))
>       return false; // doesn't provide source
> +
> +  // check for supported frequency range
> +  if(frontendType == SYS_DVBT
> +    && (Channel->Frequency() < frontendInfo.frequency_min
> +     || Channel->Frequency() > frontendInfo.frequency_max )) {
> +      return false;
> +  }
> +
>    cDvbTransponderParameters dtp(Channel->Parameters());
>    if (dtp.System() == SYS_DVBS2 && frontendType == SYS_DVBS ||
>       dtp.Modulation() == QPSK     && !(frontendInfo.caps & FE_CAN_QPSK) ||

I was just going to adopt this patch, but two questions came up:

- Is this limited to DVB-T, or would something similar also
   apply to DVB-S and DVB-C?

- With the multi-frontend support added in version 1.7.23, I
   wonder how this would work now. I assume frontendInfo can only
   hold the info on the frontend that is currently activated (via
   DTV_DELIVERY_SYSTEM). But that would mean that the delivery system
   would have to be set (and frontendInfo re-read) *before* the above
   check can be made.

Can somebody please shed some light on this?

Klaus
  

Patch

--- dvbdevice.c.orig	2010-05-01 11:47:13.000000000 +0200
+++ dvbdevice.c	2010-11-27 16:53:43.000000000 +0100
@@ -911,6 +911,14 @@ 
 {
   if (!ProvidesSource(Channel->Source()))
      return false; // doesn't provide source
+
+  // check for supported frequency range
+  if(frontendType == SYS_DVBT 
+    && (Channel->Frequency() < frontendInfo.frequency_min
+     || Channel->Frequency() > frontendInfo.frequency_max )) {
+      return false;
+  }
+
   cDvbTransponderParameters dtp(Channel->Parameters());
   if (dtp.System() == SYS_DVBS2 && frontendType == SYS_DVBS ||
      dtp.Modulation() == QPSK     && !(frontendInfo.caps & FE_CAN_QPSK) ||