When I burn CDs with nautilus-cd-burner not everything is burned to
the cd (i.e. only 400 of 650 MB), the resulting cd is corrupted and I
can throw it away. This happens regularly. On FC2 it helped when I
increased the priority of the cd burning process to -10. I can burn ok
with Windows XP.
I had the same problem in FC2.
This renders CD burning unusable for me.
I've noticed this too: all the file entries are there, but only about 60%-70% of
the actual data is written. I seem to be able to use cdrecord OK, though. This
is with kernel 2.6.10-1.770_FC3smp on my HP zx5030EA notebook with an
HL-DT-STCD-RW/DVD GCC-4241N combined DVD reader/CD-R(W) writer.
I'm seeing this problem with FC4 and nautilus-cd-burner-2.10.0-2
There is no error message, and nautilus claims that the CD was burned
successfully. cdrecord works perfectly fine.
I have some input on this bug. I just installed k3b on my FC3 system (a Dell
Precision 350), and it burns CD's with no difficulty. The disks passed md5sum
checking with the usual "dd if=/dev/hdc | md5sum", for example (contrary to
which says that one has to use ide-scsi for this on 2.6 kernels). This same
computer consistently fails to produce usable burned CD's with nautilus-cd-burner.
I used ps to find out what commands k3b and nautilus-cd-burner was using to do
the actual burn. For k3b it was
/usr/bin/cdrecord -v gracetime=2 dev=/dev/hdc speed=8 -dao driveropts=burnfree
-eject -data /mnt/t/swalton/rhelws4/RHEL4-U1-i386-WS-disc4.iso
while for nautilus-cd-burner it was
cdrecord dev=/dev/hdc -eject -v -data -nopad
Running the second command above at a shell prompt shows that cdrecord's
defaults on my machine are: -tao, no burnfree, and 32x write speed.
Just one more followup: I found that simply adding -dao to the list of options
used for cdrecord by nautilus-cd-burner seems to fix the problem. As of this
writing, I've burned two CD's this way and both pass md5sum checking.
This is beginning to look more like a cdrecord bug than a nautilus-cd-burner
bug, per se. I tried to open a new report against cdrecord, but it doesn't
appear in the list of fc3 components on the bugzilla report page.
See also bug #160191, which suggests that the -nopad option might be the issue.
*** This bug has been marked as a duplicate of 160191 ***