[vdr] [PATCH] S2API for vdr-1.7.1 vanilla and extensions patch 64 ( 071020008 )

Mika Laitio lamikr at pilppa.org
Sat Oct 18 19:10:55 CEST 2008

> you are using the older patch use the attached one.
> The fix-s2api-dvbs is not needed with this one.

I have some comment from these patches as I tried to investigate the code 
to find out why it does not work with my hvr-1300 and hvr-4000 in 
vdr-1.7.1 and xineliboutput. With vdr-1.7.0 version of these patches, the 
hvr-4000 is able to scan dvb-s channels ok but hvr-1300 fails to scan 
dvb-t channels.

One thing that looks suspicious is that the code in
dvbdevice.c function cDvbDevice::cDvbDevice(int n).
I have hvr-1300 (dvb-t) as a first device and hvr-4000
(dvb-t+dvb-s/s2) as a second device.

For hvr-1300 this method reports incorrect transport modes "DVBS DSS", 
when it should report "DVBT". For hvr-4000 it is reporting 
the "DVBS2", so it is halfly correct. I think it should report "DVBS2 
DVBT" as I am using s2-mfe drivers and thus 2 frontends created under 

Oct 18 00:00:23 tinka vdr: [28627] device 1 provides: DVBS DSS
Oct 18 00:00:23 tinka vdr: [28627] device 2 provides: DVBS2

I think there are couple of bugs in the code.
1) frontend.h in dvb-b drivers defines following types:
typedef enum fe_delivery_system {
} fe_delivery_system_t;

But in vdr-code those are compared to stings defined in following array:

const char *DeliverySystems[] = {

So both the order and amount of strings compared is different and I 
do not understand how this "if (frontendType & (1u << i))" is planned to 

If I have understood correctly this bug does not however explain why 
my hvr-1300 does not work, as in the end this for loop is only used for 
trying to detect whether the frontend type is SYS_DVBS2. For other types 
it will just printout informative debug.

2) Second problem that comes to my mind is that the code seems to assume 
that there is only 1 frontend for every adapter available, so it will not 
detect if card supports for example both dvb-t and dvb-s. I do not know 
yet, which would be the best place for making changes to support both.

More information about the vdr mailing list