Hans,

OK.  Thanks. Those messages are gone.  However, now it's exposing something
new that wasn't a problem with 0.10.0rc1.  I started losing a lot of data,
and getting another LARGE set of log messages.

I restarted my app, started reading in VBI from 8 tuners (no problem there),
and then I started reading /dev/video from 3 tuners.  In about 48 seconds, I
started getting many of the following:

Feb 16 09:07:35 server2 kernel: ivtv1: All encoder MPEG stream buffers are
full. Dropping data.
Feb 16 09:07:35 server2 kernel: ivtv1: Cause: the application is not reading
fast enough.

Then 10 seconds later, VBI buffer messages joined the MPEG messages:

Feb 16 09:07:35 server2 kernel: ivtv0: All encoder VBI stream buffers are
full. Dropping data.
Feb 16 09:07:35 server2 kernel: ivtv0: Cause: the application is not reading
fast enough.

I got about 200,000 lines of these messages between 09:00:48 (local) and
09:07:38, and then suddenly they stopped (the log messages stopped).

I checked the video from one of the tuners, and I lost about 7 minutes of
video.  The captions appear to be synchronized with the video, so I think I
lost about 7 minutes of captions as well.

Doing a vmstat at this point, the load appears to be the same as it was with
the previous version of the driver.

So, I'm a little confused, but it looks like IVTV had a buffer problem, and
then tried to recover, dropping data continuously until it finally did
recover about 7 minutes later.  And in the process, it created excessive
amounts of log messages.

It's worth noting that the program from 09:30 to 10:00 recorded the full 30
minutes of video just fine.

Maybe this was a one-time glitch.  I will continue to monitor it and let you
know if it happens again.  But it's coincidental that it happened after you
fixed the other VBI problem.

Thanks,
Rich


--

Rich Kadel
Appeligo, Inc.
(858) 433-1747
www.appeligo.com


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hans Verkuil
Sent: Friday, February 16, 2007 6:05 AM
To: Discussion list for development of the IVTV driver
Subject: Re: [ivtv-devel] System (practically) non-responsive after several
hours...no clues

Hi Rich,

Please check out the latest trunk from subversion. This bug is fixed. It 
was a subtle error resulting in these spurious errors.

Thanks for reporting this,

        Hans

On Friday 16 February 2007 02:11, Rich Kadel wrote:
> OK... Some more data for you, based on your questions:
>
> 1. It is sliced.  I am reading it from /dev/vbi[x].
>
> 2. I tried some tests.  If I just cat /dev/video >/dev/null, no
> messages appear.  In fact, I ran "cat /dev/video[x] >/dev/null"
> simultaneously with 5 tuners and saw no messages.
>
> But, then I added "cat /dev/vbi0 >/dev/null" and the following
> messages showed up:
>
> Feb 15 17:03:10 server2 kernel: ivtv0 warning: Starting VBI after
> starting an en
> coding, seems to not work.
> Feb 15 17:03:10 server2 kernel: ivtv0 warning: encoder VBI: Couldn't
> find start
> of buffer within the first 256 bytes
> Feb 15 17:03:18 server2 last message repeated 18 times
>
> I stopped all but one tuner (/dev/video0), and started "cat
> /dev/vbi0" again, and got the same message.
>
> Feb 15 17:03:35 server2 kernel: ivtv0 warning: Starting VBI after
> starting an en
> coding, seems to not work.
> Feb 15 17:03:36 server2 kernel: ivtv0 warning: encoder VBI: Couldn't
> find start
> of buffer within the first 256 bytes
>
> Then I tried starting "cat /dev/vbi0" first, followed by "cat
> /dev/video0", and I got only the message:
>
> Feb 15 17:03:36 server2 kernel: ivtv0 warning: encoder VBI: Couldn't
> find start
> of buffer within the first 256 bytes
>
> (Ignore the timestamps)
>
> So, the bottom line is, these messages appear when I read /dev/vbi
> and /dev/video at the same time.
>
> Very reproducible, and fairly constant as I said.
>
> Thanks,
> Rich
>
> --
>
> Rich Kadel
> Appeligo, Inc.
> (858) 433-1747
> www.appeligo.com
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Hans Verkuil
> Sent: Thursday, February 15, 2007 3:42 PM
> To: Discussion list for development of the IVTV driver
> Subject: Re: [ivtv-devel] System (practically) non-responsive after
> several hours...no clues
>
> On Thursday 15 February 2007 17:42, Rich Kadel wrote:
> > So far so good with 0.10.0rc1.  At least, it hasn't crashed in a
> > couple of days of continuous reading, 3 video streams, and 8 VBI.
> >
> > Now I have a new problem I'd like to resolve.  My logs are getting
> > filled up with the following message:
> >
> > Feb 12 16:00:00 server2 kernel: ivtv2 warning: encoder VBI:
> > Couldn't find start
> > of buffer within the first 256 bytes
> >
> > Occasionally, I'll notice some dropped characters in the VBI.  Not
> > often. But it could be a symptom.
> >
> > I'd like to fix the VBI problem if there's a way to do that.  If
> > not, is there a way to reduce the log messages?
>
> How are you capturing VBI? Is it sliced VBI or raw VBI? And if it is
> sliced VBI, is it embedded in the MPEG stream or captured as a
> separate stream?
>
> Do you always have these messages, or do they appear suddenly? It is
> reproducable with a simple 'cat /dev/video0 >x.mpg' command?
>
> BTW, there is no need to increase the mpeg buffers, it's not related
> to that. Basically this message indicates that something weird is
> going on with the VBI transfers. It can occur once in a while, but it
> shouldn't happen continuously.
>
> Regards,
>
>       Hans
>
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>
>
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel

_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Reply via email to