On 2005-05-06 at 14:28+0200 Johannes Stezenbach wrote: > On Thu, May 05, 2005 at 09:55:11PM +0100, Jon Fairbairn wrote: > > Using tzap -r and cat, cat dies with: > > > > cat: /dev/dvb/adapter0/dvr0: Value too large for defined data type > > > > I first saw this error when using a cvs version of tzap with > > built-in file writing abilities, [...] > > This means a buffer overflow happened, probably because > of some scheduling latencies. It is hard to avoid in > a non-realtime OS. Certainly, but we can make the probability quite low by having big enough buffers. > > Any suggestions? > > Don't use cat. Maybe "dd if=/dev/dvb/adapter0/dvr0 conv=noerror" works. > You can test by suspending (^Z) and continuing (fg). That's an improvement, though of course it loses data when the buffer overflows. Using "dd if=/dev/dvb/adapter0/dvr0 ibs=3300000 ..." allows a suspension of around five seconds, though. However, I didn't use cat anyway the first time it happened: I was using "tzap -t timeout -o file" with tzap from cvs. In tzap.c there's a line: #define BUFLEN (188*256) and if, as a random hack, I change that to something much bigger (70*188*256), I can suspend tzap for a few seconds without provoking the error. The question is, what are these numbers, 188 and 256? (My 70 there is arbitrary, but it was meant to make the buffer length correspond to a bit more than five seconds of average dvb video TS). I don't like seeing bare numbers in code like that... Presumably tzap ought also to be modified to do the equivalent of conv=noerror? How would one avoid getting a broken frame? Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk
