Jump to content

k3b won't erase cdrw


Recommended Posts

Hi,

I have no problems burning to cdrw or any other problems, but I always get this output when trying to erase a cdrw.

The disk drive is not even flashing the light to show it's being accessed/read,

however I can open the cd from Konqueror and it shows all the rw contents with no problems.

 

Have you any advice?

Maybe I should install some other rpm of k3b...

 

p.s. I'm using FC5, but thought this was more software than distro related.

If wrong, please move this to "other distributions"

 

Thanks!

 

System
-----------------------
K3b Version: 0.12.15

KDE Version: 3.5.3-0.4.fc5 Fedora-Core
QT Version:  3.3.6
Kernel:	  2.6.17-1.2157_FC5
Devices
-----------------------
TEAC CD-W540E 1.0K (/dev/hdd, ) at  [CD-R; CD-RW; CD-ROM] [CD-ROM; CD-R; CD-RW] [SAO; TAO; RAW; SAO/R96P; SAO/R96R; RAW/R96R]

Used versions
-----------------------
cdrecord: 2.1.1a03

cdrecord command:
-----------------------
/usr/bin/cdrecord -v gracetime=2 dev=/dev/hdd speed=6 -tao driveropts=burnfree -eject blank=all -force 

cdrecord
-----------------------
scsidev: '/dev/hdd'

devname: '/dev/hdd'
scsibus: -2 target: -2 lun: -2
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
Cdrecord-Clone 2.01.01a03-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2005 J?Ħrg Schilling
NOTE: This version contains the OSS DVD extensions for cdrtools and thus may
  have bugs related to DVD issues that are not present in the original
  cdrtools. Please send bug reports or support requests to
  http://bugzilla.redhat.com/bugzilla The original cdrtools author should
  not be bothered with problems in this version.
TOC Type: 1 = CD-ROM
/usr/bin/cdrecord: Device or resource busy. Cannot open '/dev/hdd'. Cannot open SCSI driver.
/usr/bin/cdrecord: For possible targets try 'cdrecord -scanbus'.
/usr/bin/cdrecord: For possible transport specifiers try 'cdrecord dev=help'.

 

[moved from Software by spinynorman]

Link to comment
Share on other sites

strange. it appears that if I wait for some time after inserting cd-rw, then k3b won't detect it,

but if I click the -erase cd- just after inserting it into the drive, everything happens

 

I think it might be something to do with Fedora doing a crappy auto-mount or something...

Link to comment
Share on other sites

On my Mandriva, K3b has no problems erasing a CDRW.

What it doesn't seem to be able to do, however, is just add some files to a CDRW without copying everything off the CDRW, erasing the whole disk and then writing everything (plus the extra files) back on again. Niggly. Is that normal for K3b? (My "other" OS is able to just slap the extra files on, which is muuuuuuch faster.)

Link to comment
Share on other sites

On my Mandriva, K3b has no problems erasing a CDRW.

What it doesn't seem to be able to do, however, is just add some files to a CDRW without copying everything off the CDRW, erasing the whole disk and then writing everything (plus the extra files) back on again. Niggly. Is that normal for K3b? (My "other" OS is able to just slap the extra files on, which is muuuuuuch faster.)

 

This is called "packet writing" and is also supported in Linux. Under "the other OS" it's done via programs like inCD.

It's also the definition of unreliability- you are guaranteed to have the CDRW destroyed and the data lost sooner rather than later.

You'd rather spend a few minutes more saving your data to HD first and then rewriting the medium than taking the risk. K3B does not act like a frontend for the packet writer tthough (thank god).

Link to comment
Share on other sites

Why is that more risky? Is there some danger that the indexes will get corrupted?

 

Exactly. Every time you add or remove a file (even a tiny one) the disc TOC ( table of contents ) is overwritten, in the same disk area, more or less.

A rewritable can take up to 1,000 rewrites, in theory, and about 200 in practice. I guess that now it's more obvious why conventional packet writing is dangerous.

It was supposed to be kicked out by the "safe" Mount Rainier writing protocol a few years ago, but the latter never cought on, and it's almost dead by now...

Link to comment
Share on other sites

OK, but when I erase the whole thing and write everything back, then I'm still overwriting the same TOC again. The only difference is that I'm also (unnecessarily) overwriting all the other parts of the disk again - seems to me that that would be more susceptible to giving errors than just overwriting a little bit of the disk, no?

 

adding extra files 200 times = rewriting TOC 200 times

wiping & rewriting 200 times = rewriting TOC 200 times plus rewriting other stuff 200 times.

 

Am I missing something?

Link to comment
Share on other sites

adding extra files 200 times = rewriting TOC 200 times wiping & rewriting 200 times = rewriting TOC 200 times plus rewriting other stuff 200 times.

Am I missing something?

 

That those 200 file adds will last less than one week, while 200 full rewrites prolly more than one year.

Link to comment
Share on other sites

Sorry to drag this thread off into a different direction, but I'd like to understand this and I don't think I get the packet writing stuff.

Now I'm not sure if I'm using packet writing or not, I'm not using InCD or anything by Nero (as far as I know!), I'm just dragging with Explorer (which doesn't write to the disk yet) and then when I've got everything together I choose "write to CD" (or something like that). Only then does the writing take place. So maybe this isn't the packet writing that you're talking about because it looks like the TOC is only updated once and only when I've finished. So as far as I can tell, when I want to add some files to the CD (which may be once a month), the files are added and the TOC updated.

Using K3b, I still want to update the CD about once a month, except when I do that I can't just add the files and rewrite the TOC, I have to wipe the disk and rewrite everything.

 

So they're both still once a month, the TOC still gets rewritten once a month either way (not 200 times a week!) except with K3b it's waaaaaaaaay slower and rewrites much more of the disk each time.

 

So doesn't that mean the K3b way is going to make the CD fail more quickly?

Link to comment
Share on other sites

Looks like you are using the Imapi CD/DVD writing service (available only on Windows XP professional, unless I'm missing something), which IS a packet writer (factly, it is a very basic implementation of the older Adaptec/Roxio DirectCD software, lacking features and defect management tools).

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...