Michael Smith wrote:
Are you burning the iso images as a single file, or creating a cd from the iso images?
I've done mostly ISO files. But for the files that I made CDRs of, it had like results.
I'm getting ready to burn a CDR with all ogg files on it. I'll report what it does on my work machine.
I haven't ever looked for an update to the burner's firmware yet. It might need an upgrade.
My ACER burner is a 12x8x32 speed unit. I got it when I was still using a 166 MHz packard bell machine.
It worked great until I upgraded to 8.0. Then there were disc errors present. At first, I wrote it off as a bad cd reader within my laptop. Then I saw errors on my work XP machine and on audio CDRs that I have burned. Before 8, they all worked excellent.
My reader is whatever comes with a PowerSpec computer. It is 52x max. It checksummed my phoebe discs alright. It was erratic with trying to install with them though. Sometimes the screen went blank and I had to ctl-alt-del my way out of the installer.
The same discs failed mediacheck on my laptop 490CDT Toshiba. They hunted and gave all sorts of errors. The discs would boot, but the discs weren't good to install with.
I tried to burn the discs on RH7.3 and the discs didn't fail the mediacheck on my laptop and then burned the same ISO for a test on phoebe3. It was full of errors. Except, I killed magicdev before the burning, so there were a few less erros reported on the disc. But not good enough to use.
Jim
For what it's worth I have an ACER CDR that I bought last Oct. It was working great and then I started getting some strange errors that I attributed to bad media. All of a sudden the the writer couldn't read any media. I took and back and they replaced it.
Gerry
The device read CDRs alright. I did have a problem with some changing symlinks upon bootup. It tried to use the /dev/hdd driver and would not mount properly.
I changed it to /dev/scd0 and it mounted alright for reading.
The trouble that I hade with kernels 2.4-2.48 was the entry would change back if kudzu was present in the /etc/fstab entry. It would change the link back to /dev/hdd. When I took out the kudzu parameter. It would leave that entry and symlink to the device intact. But it would creat another entry for the Acer burner, add an entry into /etc/fstab and create an additional symlink to /dev/cdrom3. I left the link alone and used my edited link.
Then I installed and booted kernel 2.4-2.53 (Rawhide). When I booted this kernel. I ended up getting all of my cdroms designated as /dev/scdx devices. This left my /etc/fstab file with three cdrom entries, in the /etc/fstab file. The entry for my cd reader, which was /dev/hdc was gone. It was now designated as /dev/cdrom3 and symlinked to /dev/scd0.
The symlink to /dev/cdwriter was changed from pointing to /dev/sg0 to pointing to /dev/sg1. Now my only problem seems to be that the burn:/// window of nautilus opens a window, when a disk is inserted in /dev/scd1 (Acer burner) and tries to burn to /dev/sg0, which seems to be my reader.
All is not lost though. It doesn't kill a disc. But it does error out and seems useless, until it is fixed.
Anyway, I burned a disc with xcdroast and it did not give any errors on my work computer. I cycled through all of the oggs and no disk or atapi errors were reported in the event viewer logs. I guess holding back magicdev has helped a bit. I feel a bit more at ease with the quality of the burned discs.
The only change that I made to xcdroaster was to increase the buffer from 4 to 16. I have 512 meg, so I think it migh have helped some.
I'm entertained with this problem. I was wondering if enabling DMA in the kernels, for cdroms, has caused them to be "seen" as scsi devices. They work alright! It seems that the applications, like burn:/// just need to take the reaction, into account.
Jim C.
-- A good reputation is more valuable than money. -- Publilius Syrus
