GNOME CD burner hangs on "Write to Disc" dialog

[Paul Natsuo Kishimoto]

Binary package hint: nautilus-cd-burner

I upgraded from Dapper Drake to Edgy Eft using the gksu "update-manager -c" method. My optical drive is a HL-DT-ST DVDRAM GSA-4167B that worked perfectly before the upgrade.

Steps to repeat error:
1. Open home directory, show hidden files with ctrl-H.
2. Insert blank DVD-R in drive. In the "Choose Disc Type" dialog, click "Make DVD".
3. Drag all files from home directory to CD/DVD creator.
4. Click "Write to Disc"

Expected behaviour:
"Write to disc" dialog appears with all controls disabled and "Calculating..." listed by "Data size". Trying to close the window causes the "not responding" dialog to appear.

I've tried "dmesg | tail" at the console, but the last relevant message is:
cdrom: This disc doesn't have any tracks I recognize!

[Martey Dodoo (martey)]

I can confirm this bug on a fresh install of Edgy.

It does not occur when only a few files or folders are copied to burn:///, but does when I try coping most of my home folder. When hidden folders were not selected, the hanging stops when I removed a folder containing source code and a couple of Subversion trees from the CD/DVD Creator.

[Christopher Barrington-Leigh (cpbl)]

Same problem here, with the latest fresh edgy, but I am not trying to copy a complex structure.

I am just trying to burn three shallow directories albeit with lots (2000) files adding up to not much (100 MB). I cannot get it written, neither to the CD nor to an ISO file.

The greyed-out dialog actually becomes ungrayed if a second nautilus burn:/// is opened, a write attempted, and then the application is killed violently. But then the first dialog, now ungrayed, still hangs immediately.

This seems a rather fundamental operation failure.

[Paul Natsuo Kishimoto (khaeru)]

I have a hunch that the problem is Nautilus trying to cache (or otherwise manipulate) files for burning that are being used/locked/something by other active processes.

Unfortunately, I've got no way to confirm this hunch. If a developer could indicate what kind of debug info I could provide to help do so, I'd be glad to comply.

[Martey Dodoo (martey)]

It is worth noting that the problem still occurs in the lastest Feisty package (2.17.3-0ubuntu1). Changing nautilus-cd-burner's "debug" GConf value to true and running it from the command line does not produce any output.

[Sebastien Bacher (seb128)]

Thank you for your bug. Does it use lot of CPU while hanging? Could you install nautilus-cd-burner-dbg and get a debug backtrace as described on https://wiki.ubuntu.com/Backtrace?

[Ted Anderson (ota-surfvi)]

I am also seeing this problem. Responding to the request for debugging information from Sebastien, here is some data I hope will help.

There are two processes running:
ps auxw|grep burn
ota 21399 0.7 1.4 8856 7248 ? S 17:28 0:00 /usr/lib/nautilus-cd-burner/mapping-daemon
ota 22787 3.1 2.5 37552 13016 ? S 17:30 0:00 /usr/bin/nautilus-cd-burner

As you can see they are using a trickle of CPU, but hardly looping.

I have the gdb backtrace information for both of these processes attached.

I added these packages:
nautilus-cd-burner-dbgsym (2.16.1-0ubuntu1)
libnautilus-burn4-dbgsym (2.16.1-0ubuntu1)

My system information is this:
[~]% nautilus-cd-burner --version
Gnome nautilus-cd-burner 2.16.1
[~]% lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 6.10
Release: 6.10
Codename: edgy
[~]% uname -a
Linux alohomora 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 GNU/Linux

HtH,
Ted Anderson

[Ted Anderson (ota-surfvi)]

Here's the backtrace for the mapping-daemon. -ota

[Sebastien Bacher (seb128)]

thank you for your work on that, could you get a backtrace with libgnomevfs2-0-dbg installed?

[Ted Anderson (ota-surfvi)]

Here is the gdb backtrace from nautilus-cd-burner with gnomevfs symbols installed. It is quite a bit more informative. In particular, it seems to be stuck opening the directory "/Aladdin/aka-home/Cookies" which is a backup copy of (old) IE cookies. There are
3466 small files in that directory.

The mapping-daemon trace is essentially identical so I am not attaching another copy.

HtH,
Ted

[Sebastien Bacher (seb128)]

That looks the same problem than bug #72284, marking duplicate