<br><br><div><span class="gmail_quote">On 9/23/05, <b class="gmail_sendername">Mark Knecht</b> <<a href="mailto:markknecht@gmail.com">markknecht@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 9/22/05, Mark Knecht <<a href="mailto:markknecht@gmail.com">markknecht@gmail.com</a>> wrote:<br>> On 9/22/05, Robert Tsai <<a href="mailto:rtsai1111@comcast.net">rtsai1111@comcast.net</a>> wrote:<br>> > On Thu, Sep 22, 2005 at 06:52:15PM -0700, Mark Knecht wrote:
<br>> > > Thanks very much.<br>> > ><br>> > > I did have it set to one job, but CPU usage was medium so I've set it<br>> > > to low. Additionally I saw an option to start commercial flagging when
<br>> > > recording starts. I've disabled that also, at least as a test.<br>> > ><br>> > > Probably 70% of our recording is late night stuff so commercial<br>> > > flagging can get done between 3AM and 7AM and probably cause no
<br>> > > problems at all.<br>> ><br>> > I think your real problem was commercial flagging when recording<br>> > starts (a.k.a. "real-time commercial flagging).<br>><br>> Could be. Now that I know where the setting are I can play with that a bit.
<br>> ><br>> > You might be OK bumping CPU usage back up to medium so that<br>> > commflagging can go faster. The nicing should prevent mythcommflagging<br>> > from interfering with recordings. But I don't know the details of your
<br>> > capture cards, maybe you need more CPU for software encoding.<br>><br>> 3GHz P4HT but currently a UMP kernel.<br>> PVR-150<br>> PVR-250<br>> 512MB<br>><br>> 250GB storage over NFS in another box so good networking matters.
<br><br>Hi Robert,<br> Well, last night's recordings mostly failed again:<br><br>8PM - 1 30 minute show - recorded fine. Recording info says 30 minutes long<br><br>10PM - 2 30 minute shows. Both failed. One is 18 minutes, the other is
<br>19 minutes.<br><br>11PM - 1 30 minute show - looks good<br><br>11:30PM - 2 60 minute shows - both failed - One is 22 minutes, the<br>other is 25 minutes<br><br>12:30PM - 1 60 minute show - failed. Info says 37 minutes.
<br><br> Looks like I've got more problems than just the settings we played<br>with yesterday. However, a question - Did I need to restart the<br>backend server to get those changes to take effect? I didn't do that.<br>
<br> I'll try that this morning as a test.<br><br> Here's the failure messages in dmesg"<br><br>ivtv: ENC Stream 0 OVERFLOW #57: Stealing a Buffer, 512 currently allocated<br>ivtv: ENC Stream 0 OVERFLOW #58: Stealing a Buffer, 512 currently allocated
<br>ivtv: ENC Stream 0 OVERFLOW #59: Stealing a Buffer, 512 currently allocated<br>ivtv: ENC Stream 0 OVERFLOW #60: Stealing a Buffer, 512 currently allocated<br>ivtv: ENC Stream 0 OVERFLOW #61: Stealing a Buffer, 512 currently allocated
<br>ivtv: ENC Stream 0 OVERFLOW #62: Stealing a Buffer, 512 currently allocated<br>ivtv: ENC Stream 0 OVERFLOW #63: Stealing a Buffer, 512 currently allocated<br>mark@dragonfly ~ $</blockquote><div><br>
<br>
You've very likely got other problems if you are having those problems
with that set up. Have you checked for things like IRQ conflicts,
and made sure you are using a current IVTV that's configured correctly,
made sure DMA is enable on your drives, that sort of thing? With
the two PVRs, your CPU really shouldn't enter much into it as far as
recording goes. Your problem is likely to be elsewhere. <br>
</div><br></div><br>