On 12-11-29 10:50 AM, Andy Walls wrote: > > Hi Ezequiel, > > Nope. IIRC, that's just MythTV timing-out, closing the device node, and > reopening the device node, in attempt to make things work again. Seems a very reasonable explanation. > Hi Brian, Hi Andy, > I haven't checked the log you provided yet, but you'll likely need to > set the module debug flags a little more verbose. OK. > /sbin/modinfo ivtv | less > [...] > parm: debug:Debug level (bitmask). Default: 0 > 1/0x0001: warning > 2/0x0002: info > 4/0x0004: mailbox > 8/0x0008: ioctl > 16/0x0010: file > 32/0x0020: dma > 64/0x0040: irq > 128/0x0080: decoder > 256/0x0100: yuv > 512/0x0200: i2c > 1024/0x0400: high volume > [..] > > So maybe as root > > # echo 0x07f > /sys/module/ivtv/parameters/debug > > until the problem appears. Then once you experience the problem change > it to high volume Will waiting for MythTV to report an error, such as: MPEGRec(/dev/video1): Device error detected be too late to turn up debugging or should that be sufficient enough timing? Although, MythTV seems to report that error at the end of every recording so I'm not sure how I will filter out the false reports -- unless I write a smarter (i.e. than a single line match) log watcher. Anyway, that's my problem, not yours. :-) > # echo 0x47f > /sys/module/ivtv/parameters/debug > > You may want to also get a baseline of what a good capture looks like > using high volume debugging. Just did that. Reduced to 0x07f after about a minute and 23 seconds. > Be aware that high volume debugging will > fill up your logs and degrade performance a little, so you don't want to > normally use high volume debugging. Indeed, it's quite verbose. > +1 > > The ideas or interest of one individual often spurs that of others. Indeed, I always keep list replies on list and as I mentioned to Ezequiel (sorry Ezequiel, I got your name wrong on my previous post. my apologies) and I am seeing the copies -- but through gmane. I don't see the copies on the spincs.net archive. I suspect there is a lag at gmane posting to the list. In any case, I have CC'd this one directly to the list @vger.kernel.org and will just hope it has an open posting policy. Cheers and thanks much! b.
Attachment:
signature.asc
Description: OpenPGP digital signature
