Comment 7 for bug 260251

Thanks for the link ciril.
Having a look at the both the current svn and the current package in intrepid they both contain that patch to fix the EAGAIN. It looks like any other errors will still cause opencv to terminate. In my case the bttv card returns error 5, EIO, which according to the the V4L spec may or may not indicate a serious error. While I'm quite tempted just to patch it locally to get the thing to work, I'd rather fix this bug propperly.

From http://v4l2spec.bytesex.org/spec-single/v4l2.html#VIDIOC-QBUF :
EIO: VIDIOC_DQBUF failed due to an internal error. Can also indicate temporary problems like signal loss. Note the driver might dequeue an (empty) buffer despite returning an error, or even stop capturing.

http://opencvlibrary.svn.sourceforge.net/viewvc/opencvlibrary/trunk/opencv/src/highgui/cvcap_v4l.cpp?revision=1428 :
 1169 if (-1 == xioctl (capture->deviceHandle, VIDIOC_DQBUF, &buf)) {
 1170 switch (errno) {
 1171 case EAGAIN:
 1172 return 0;
 1173
 1174 case EIO:
 1175 /* Could ignore EIO, see spec. */
 1176
 1177 /* fall through */
 1178
 1179 default:
 1180 /* display the error and stop processing */
 1181 perror ("VIDIOC_DQBUF");
 1182 return 1;
 1183 }
 1184 }

There's also a lot of warnings in dmesg generated by the card:
bttv0: timeout: drop=15799 irq=1410075/32669932, risc=21789a2c, bits: HSYNC OFLOW

I'm really not quite sure if this is a opencv bug (should it be ignoring EIO?) or a bttv bug (should this even be throwing EIO?). It's not exactly clear from the V4L2 spec what the proper response should be. Having a look at GStreamer's v4l2 code ( http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/sys/v4l2/v4l2src_calls.c ) shows a fair bit of buffer checking to try and safely recover from this error, though I'm not sure I quite understand what it's trying to do at a glance. Any ideas?