[mythtv] Some bugs (0.15)

[David]

Chris Pinkham wrote:

>>Chris Pinkham wrote:
>>
>>    
>>
>>>Theoretically with this, I think you could setup a dedicated commercial
>>>detection backend on a machine by running a copy of mythbackend with
>>>no TV cards defined on that server.
>>> 
>>>
>>>      
>>>
>>Which is exactly how I plan to use it.
>>    
>>
>
>You might like another feature I added then as well.  There will be a new
>setting to give you a little control over how much CPU the flagging threads
>use.  It has 3 values:
>
>Low - this is the existing way and default setting.  The flagging is run
>	in a niced thread and sleeps a little after processing each frame to
>	make sure it doesn't cause problems with anything currently recording.
>
>Medium - The flagging is run in a niced thread but doesn't sleep any so it
>	will run faster than "Low" but isn't as nice to other processes since
>	it doesn't voluntarily give up CPU time by sleeping.
>
>High - The flagging is run full-throttle.  NO nice(19) and NO sleeping.  The
>	faster your CPU is, the faster the flagging will finish.
>  
>
Hmm

You're talking about running io intensive operations on a remote box: on 
my backend system (PVR350, athlon 1800+, KT600, kernel 2.6.4) I have 
problems running remote I/O intensive activities whilst Myth is recording.

I haven't bottomed it out yet.

I suspect that putting a very high I/O load (nfs, disk io, 100Mb 
network) on the mythbackend is causing ivtv to fail.

I'm looking at the ivtv config (saw something about upping the buffers), 
renice'ing (-1) mythbackend (will this help ensure recording has ivtv io 
priority?), renice'ing (+1) nfsd (to reduce priority of nfs serving) as 
ways to allow it to be a reliable video server for io intensive stuff 
(mpeg indexing for me, commercial flagging for you).

Any similar behaviour? Any suggestions?

David