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