After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 355982 - burning multiple copies of a CD is excruciating (unreliably recognized CD-Rs)
burning multiple copies of a CD is excruciating (unreliably recognized CD-Rs)
Status: RESOLVED FIXED
Product: nautilus-cd-burner
Classification: Deprecated
Component: cd-burner
2.14.x
Other All
: Normal normal
: ---
Assigned To: Nautilus CD Burner Maintainers
Nautilus CD Burner Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-09-14 16:11 UTC by Stefan Monnier
Modified: 2006-12-04 20:51 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description Stefan Monnier 2006-09-14 16:11:53 UTC
Please describe the problem:
At the end of writing the first CD, I get asked: "eject/make another copy/quit".  First, it's not clear exactly whether I should hit eject before clicking "make another copy", so the interface is a bit imprecise.  But the behavior was even worse, so I still don't know whether I should eject before or not.

The main problem (clearly a bug, maybe in HAL) was that after inserting another CD, nautilus-cd-burner would burp at me saying "please insert a new CD with
sufficient space blablabla" even though the CD I had just installed was indeed blank.  The CD was detected because the dialog box did include an "eject" button.  I then tried to click "OK", or first "eject", then "OK", and other variations, but none worked except for: click "eject", then re-close the CD slot manually, then wait a little for the disk to spin, then finally click "OK".  It's not clear if the wait was necessary, but the rest seemed to be indispensable.

Usabilitywise, the fact that the disk is not automatically ejected when the dialog about "insert a new blank CD" pops up is rather odd: how am I to insert a new CD other than by first ejecting the current one?

Steps to reproduce:
1. set things up for wrinting, select "write CD"
2. when the write is done, press "eject"
3. then insert a new blank CD-R disk
4. then press "make another copy"

You can also try to not click "eject" and instead to immediatly click "make another copy" and quickly replace the previous CD with the new one as cd-burner opens&closes the drive slot.  Same thing.

Then you should get the incorrect complaint about the CD not being blank.  Click "OK" and notice that after a short while it comes right back still complaining that the CD is not blank.


Actual results:


Expected results:


Does this happen every time?
Yes, although I have felt like there was a part of non-determinism in the way the thing failed.  Probably simply because there are sufficiently many different ways to do things (whether you open the drive-slot via "eject" or manually by pressing the button on the drive itself, same thing for closing it, and in which order you do them) and I kept trying a different one to see if some magical order worked better (I was burning a large number of CDs and it was already getting late).

Other information:
This is on a GNU/Linux Debian testing system (AMD64 X2 running in i686 mode, with a DVD/CD player that looks like the following:

# cat /proc/ide/hda/model 
HL-DT-ST DVDRAM GSA-4167B
# cat /proc/ide/hda/driver 
ide-cdrom version 4.61
# cat /proc/ide/hda/settings 
name                    value           min             max             mode
----                    -----           ---             ---             ----
current_speed           66              0               70              rw
dsc_overlap             0               0               1               rw
init_speed              12              0               70              rw
io_32bit                0               0               3               rw
keepsettings            0               0               1               rw
nice1                   1               0               1               rw
number                  0               0               3               rw
pio_mode                write-only      0               255             w
unmaskirq               0               0               1               rw
using_dma               0               0               1               rw
#
Comment 1 William Jon McCann 2006-12-04 20:51:50 UTC
Things should be a bit better now.  We eject all completed discs by default now.  We still have the problem when a disc has been inserted but HAL hasn't told us about it yet.  I'll mark this as fixed (kinda).