10 40 soemthing) under linux (debian3 kernel 2.4.18). I can't seem to write a CD without getting errors on it (i.e. a diff with the orginal show differences).

This can be really frustrating. The first burner I owned had a h/w fault and I wasted a lot of time - and blank media at nearly a pound a throw in those days - until I realised what was happening.

If all s/w settings are correct, and the drive is not faulty (have you tried it under any other OS - simply for comparison) then the problems may be with the media itself.

These include poor-quality media, media not rated for the burning speed used or a mismatch between media and burner (i.e. not all burners will handle all media reliably although this is less of an issue recently).

I suggest you try a different type of blank, preferably a good quality product from a name brand such as Kodak Gold, TDK Reflex or Verbatim Datalife Plus, using only 650M (74min) or 700M (80 min) capacities (650 recommended until all is known to work smoothly).

If you still have no luck and you live near Norwich, contact me off-list.

HTH and good luck! Syd

Are your CD blanks rated for that speed? However good the hardware you cannot go faster than the media will take.

On 23-Oct-2002 Jonathan Dye wrote:

Hi guys,

I'm having problems writting CD's (It is an IDE cd writer Acer 20 10 40 soemthing) under linux (debian3 kernel 2.4.18). I can't seem to write a CD without getting errors on it (i.e. a diff with the orginal show differences). What seems to be happening is that I'm getting buffer underrun on the drive as it stops writing momentarily. I can't see why as I have cdrecord's fifo set to 16Mb and it doesn't drop below 90%, the writer is on it's own channel and even if I did get under-run the drive is supposed to have BURN-Proof which according to cd-record is switched on. I've tried slowing down the writing from 20x to 8x and still got a bad write (although I didn't notice the drive stop writing but I didn't watch for the whole 10 mins). I've also tried turning DMA on and off by using hdparm on the /dev/hd* entires (which seems to work even though I'm using ide-scsi) and turning it off means I can't spool data quick enough for 20x anyway. I was hoping someone would have a suggestion as to what I could do to stop this happening (appart from buy scsi!). I'm currently compiling the kernel with less crud and the preemptive patch to see if that improves the situation.

JD