Hi,
I will ike accentuate the do {}while(0) behavior. I've seen this in few projects including VDR and at least one plugin (xineliboutput) In a code like: do {
if (condition1) continue; } while(condition2); continue does not translate to a jump to "do", but to a jump to "while" where the condition2 is evaluated.
do { if (condition1) continue; } while(0);
if equivalent with: do { if (condition1) break; } while (0);
Regards, Ilariu On 2/18/07, Reinhard Nissl rnissl@gmx.de wrote:
Hi,
Dieter Bloms wrote:
my primary dvb card works fine on both of my Twin-LNB connectors. I can switch the second card via szap and get a video stream via "cat /dev/dvb/adapter1/dvr0 > /tmp/bla" on H and V channels. VDR doesn't get data any data from H channels, but gets data from V channels. I will try to strace vdr and szap to get any difference, maybe they do it in a different way.
I've had a further look into szap's source how it detects the status FE_LOCKED. Attached is an updated tuner patch which now also reports details for FE_READ_STATUS.
One difference between VDR and szap regarding FE_READ_STATUS is, that VDR only honors the read status when ioctl() returns 0 while szap prints just an error when ioctl() returns -1.
Furthermore, VDR's handling of errno == EINTR seems to be wrong due to the do {} while (0); loop.
BTW: I still assume, that your logfile reports a tuning timeout. If this is no longer the case, then you may want to experiment with WAIT_FOR_TUNER_LOCK in device.c.
Bye.
Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr