[vdr] Re: Broken recordings (many mpeg errors and artifacts)

[Carsten Koch <Carsten.Koch@icem.de>]

bobdylan23@web.de wrote:
> 
> vdr@linuxtv.org schrieb am 22.07.02 13:29:34:
> 
> > Could someone find an explanation for this really strange symptom?
> 
> Now the vdr is crashing every 1-2 min., but only during recordings and
> only at Pro7 & Co. The /var/log/messages shows an increasing buffer.
> When it reaches 100% comes an EPG Error/Bug.

The log messages you quoted show that vdr is unable to get the
data written out as fast as they come in. 
Obviously, this works better on channels with a lower data rate
and worse on channels that require more data per second to be
written to the hard disk.

The message about standard violations in the EPG data is totally
unrelated, but you are not the first one who was confused by it.
Maybe the message should be rephrased to make it 100% clear that
it was issued after a vdr abort due to causes unrelated to the EPG.

Back to the real problem: Klaus has already answered it. It is most
likely related to a lack of DMA on your /video disk. At least that
is the most common reason why your disk is unable to accept the data
as fast as they are coming in.

I have posted a test program a while ago that shows you the effective
read and write rate on your disk. Search the mailing list archives
for disk_test.cpp and run this program on your disk. If it gives 
you much less than 20MB/s, you do have a problem. If it uses over 90%
of the CPU while writing, you almost certainly do not have DMA.

Of course there are other reasons besides "no DMA" that may slow
down a disk while writing. A little known fact is that some manufacturers
ship their disks with "write verify" enabled for a number of power
cycles. For example, Maxtor does that. You can download a DOS program
from their web site to turn "write verify" off, or you can simply 
turn the computer power on and off about 20 times (not recommended)
to get rid of it. Other reasons include bad sectors, a driver problem
with that disk type, other processes tying up resources, etc, etc.
The fact of the matter remains: your data cannot get written as fast
as they come in. Solve that problem and your recordings will work.
It is almost certainly NOT a VDR bug.

Carsten.