Before you buy a new one, at least try what I said, I've had the same damn problem, and it's miraculous, but it worked. Certain drives and versions of growisofs cause a strange incompatibility with ext3 fs on the HDD, something to do with I/O that causes nearly all DVD burns to fail. This happens with my crappy laptop DVD burner, which can barely burn a DVD properly, using ext3 it will not burn any DVD properly, with other filesystems it can. I can't really explain it, but there was an article on this somewhere, I'll see if I can find it again, I know I posted this before tho.

I'm not saying it for sure is this problem, but when it starts becoming such an odd issue that nothing will solve, the chances get higher that it might work.

It's funny, every time I post this rather insane solution, people think I'm mad or wrong. Heheeh, it's funny

Hey I dont think you're mad/insane. It's just that i'm not in a hurry to tear my system down and use another FS. And the other issue is that this was working fine previously with ext3. I'm in the process of building a new box at this point with some server grade hardware. I never had much faith in that cheapie biostar motherboard, even though windows with the supplied nvidia chipset drivers has no problems.

I had de same problem and still can't get the best of my Plextor SATA DVD recorder... impossible to reach 16x. I suspect it's a problem with K3B and how the Nforce modules deal with ATAPI.

With my previous IDE drive performance was pathetic. With SATA improved a lot, but not as well as expected.

_______________________
ASUS M2N-E
AMD Athlon 64 X2
2GB Ram
Debian testing up to date
2.6.24-1-amd64 #1 SMP

Have you tried what I said above about switching filesystems ? I had the same problem, the DVD burner would not burn at max speed, then when I switched filesystems it suddenly works perfectly. At least try it, maybe on a separate partition or something.

Thanks H_TeXMeX_H, interesting idea.

Well, which filesystem do you suggest to try? Any special tuning or mount options? Maybe the problem is with journaling filesystems where you store the fifo buffer. I'm using reiserfs under LVM now.

You mention an aditional source of info over there, it would be great if you could post it here.

If you're using resierfs then the filesystem is probably not the problem, it only happens with ext3 AFAIK. If you wanted to you could try XFS or JFS, but in your case it won't help. If you have the newest versions of everything then I can't explain it either. Maybe it was some other factor that I changed that fixed the issue. I changed too many variables at once and I can't tell which one was responsible. I just read that ext3 could cause problems like this and blamed it on that. I may be wrong to do so.

Hi,
I am also having the same problem with K3b running opensuse 10.3 - using kernel 2.6.22.17-0.1.
I am a newbie so not sure what it is.
My drive is TSS H552U (Samsung) on firmware US03.
I have seen somewhere else that Firmware updates change things - some for better, some for worse!
I have no idea how to rebuild kernels and some of the stuff you been talking about. But I sure would like to find a solution to this as I don't run M$ so can't write any media for boot disks etc.

i have revisited this issue once again on the same system after another fresh OS install. The box is now Slackware 12.2 running custom 2.6.28 kernel. This time around I've poked and prodded at things a bit further and have now found a workaround that has proven itself across several dvd burns. I have no explanation as to the WHY this works so well so feel free to fill me in..

K3b: 1.0.5
growisofs version 7.1
mkisofs 2.01.01a53
Cdrecord-ProDVD-ProBD-Clone 2.01.01a53

all of these attempts were done with speed=16x

k3b acts as a frontend gui to growisofs for dvd burns which itself works together with mkisofs. repeated dvd burn attempts with k3b here hover around 4x-6x max and from past experience these usually lead to a small percentage of files which fail md5sum checks... so let's just scratch k3b off the list again and move on to the commandline!

attemping to burn 'on the fly,' meaning growisofs would create the iso and burn simultaneously, from the commandline using growisofs lead to similar poor speed as when using k3b .. hmm! so lets dissect this a bit further. maybe the 'on the fly' aspect is hitting a cpu/disk bottleneck of some sort. so i then used mkisofs and created the dvd iso first and afterwards then ran growisofs to burn the iso ...
... AMAZING we are now seeing speeds going over 10x .. BUT .. every time I would attempt this (with -use-the-force-luke=dummy) the speeds would steadily ramp up towards 12x but approximately 70% through the burn the UBU (unit buffer?) would drop drastically until it was around 10-20% and then the speed would just drop to around 6x until the end of the burn. So basically it would max around 12x and then appear that the UBU (buffer) would run out and then the speed drop would follow. I left a 'top' process running during the burns to see if memory/swap was running out or anything unusual with cpu/mem usage spikes and it was remaining pretty constant through the entire burn processes. I also tried increasing the buffer from 32m to 128m with no improvement.


finally .. i decided to take the iso i had created with mkisofs previously and just for fun see how cdrecord handled it ..
SURPRISE .. cdrecord burns dvd flawlessly at max speed 16x every time. It ramps the speed up faster than growisofs and is consistent in achieving max speed. The fifo remains at 90-100% and the buffer at 85% during the entire burn. This may have to do with setting the burnfree option though I cannot say.



One other "fun" quirk I noticed with this system when compiling this latest kernel is that if I use pata (CONFIG_PATA_AMD=y) rather than the traditional ata/ide module, every *cd* I burn with cdrecord ended up with files failing md5sum checks... I checked and double checked this and the only way to resolve this was to use the traditional ata/ide (CONFIG_BLK_DEV_AMD74XX=y) after which all burns go through flawlessly/

Burnfree is a technology used to prevent buffer underrun "a state occurring when a buffer used to communicate between two devices or processes is fed with data at a lower speed than the data is being read from it." So in this case the HDD is too slow for some reason.

If you have a SATA HDD, put it in AHCI mode, and issue should resolve itself.

If it is IDE, then make sure DMA is enabled. There is also an ext3 related bug that can cause this, this is why I resolved this issue on my laptop by switching filesystems.