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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] _______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr