f-spot problems while exporting file to cd - Unable to create CD

[Jens Gersdorf]

Binary package hint: f-spot

Using f-spot from edgy (f-spot 0.2.1), I have problems exporting images to the cd.

I select some images, export them to cd. F-Spot looks like it is copying the files to the temporary directory where all files are stored that should be burned. But then, when it starts up the cd burn frontend, it shows the following message:

In german: "CD/DVD konnte nicht erstellt werden. Keine Dateien ausgewählt."

The message translated to english should be
Unable to create CD/DVD
No files were selected.

There seems to be some one else having this problem on ubuntu, see
http://gnomesupport.org/forums/viewtopic.php?t=11834

Strange thing is that this problem does not occur if there is already lying some file in the CD "Burn" location. Then everything is working fine. But if you delete this file again from the burn location and export an image from f-spot, you have the problem again.

Regards

Jens

[Jens Gersdorf (jens-gersdorf)]

I was able to reproduce the error on a second ubuntu edgy eft pc.

[Andrew Mitchell (ajmitch)]

I'll look into this, and see if I can reproduce on feisty. If you are able to test with feisty also, that would be appreciated

[Andrew Mitchell (ajmitch)]

From what I can see, this appears to be fixed with feisty

[Jens Gersdorf (jens-gersdorf)]

This bug is still in feisty - confirmed again on two notebooks running feisty.

Regards

Jens

[Jens Gersdorf (jens-gersdorf)]

Hi,

I know realized that it seems to be a timing problem - sometimes cd burning works, sometimes not.

I just did some statistics: From 13 tries to export files to cd, on my notebook it only worked 3 times. Perhaps my notebook is to slow - its a Pentium 4 Mobile running on 1,2 - 1,9 GHz...

I also add a screenshot of the error.

[Jens Gersdorf (jens-gersdorf)]

Hi,

I just analyzed the problem a little bit on my machine.

My first thought was, that there is a timing problem. Therefore, I got the
sourcecode from the Ubuntu repository, and patched the File CDExport.cs to
include a sleep of 10 sec before it calls nautilus-cd-burner in the Transfer()
Method:

--------- extract from CDExport.cs -------------

                                if (result == Gnome.Vfs.Result.Ok) {
                                        System.Console.WriteLine("#####
Gnome.Vfs.Xfer.XferUri returned OK");
                                        System.Console.WriteLine("##### Due to
bug, sleep 10 sec");
                                        System.Threading.Thread.Sleep(10000);
                                        System.Console.WriteLine("##### Sleep
done, now it shoud work hopefully");
                                        progress_dialog.Message =
Catalog.GetString ("Done Sending Photos");
                                        progress_dialog.Fraction = 1.0;
                                        progress_dialog.ProgressText =
Catalog.GetString ("Transfer Complete");
                                        progress_dialog.ButtonLabel =
Gtk.Stock.Ok;
                                        progress_dialog.Hide ();
                                        system ("nautilus-cd-burner");
                                } else {

-------------

Well, I don't know if that was a stupid idea, but it did not change the
behaviour (besides the effect that I had to wait 10 secs in each trial to
export files to cd...). That is, sometimes (seldom) it works, and very often it
does not work.

During my trials, I examined the directory /tmp/virtual-jens.oVFB78t, where all
the exported photos seems to be copied. The interesting thing is that although
nautilus-cd-burner complains that no files have been selected for burning,
f-spot (or the gnome-vfs) copies files to this directory.

After 10 tries (each with two photos selected for export), the directory looks
like the following:
jens@toshiba:/tmp/virtual-jens.oVFB78$ ls -lrt
insgesamt 3960
-rw-r--r-- 1 jens jens 186401 2006-12-27 20:13 file.I898TT
-rw-r--r-- 1 jens jens 207567 2006-12-27 20:13 file.0WEWTT
-rw-r--r-- 1 jens jens 186401 2007-06-24 18:13 file.KG13TT
-rw-r--r-- 1 jens jens 207567 2007-06-24 18:13 file.IMEEUT
-rw-r--r-- 1 jens jens 186401 2007-06-24 18:14 file.H4VDUT
-rw-r--r-- 1 jens jens 207567 2007-06-24 18:14 file.6UMZTT
-rw-r--r-- 1 jens jens 186401 2007-06-24 18:15 file.BEL7TT
-rw-r--r-- 1 jens jens 207567 2007-06-24 18:15 file.0C2EUT
-rw-r--r-- 1 jens jens 186401 2007-06-24 18:15 file.VLLVTT
-rw-r--r-- 1 jens jens 207567 2007-06-24 18:15 file.P8B6TT
-rw-r--r-- 1 jens jens 207567 2007-06-24 18:15 file.UTEBUT
-rw-r--r-- 1 jens jens 186401 2007-06-24 18:15 file.4BX0TT
-rw-r--r-- 1 jens jens 186401 2007-06-24 18:16 file.IDO1TT
-rw-r--r-- 1 jens jens 207567 2007-06-24 18:16 file.FWC9TT
-rw-r--r-- 1 jens jens 186401 2007-06-24 18:16 file.9VS9TT
-rw-r--r-- 1 jens jens 207567 2007-06-24 18:16 file.13SVTT
-rw-r--r-- 1 jens jens 186401 2007-06-24 18:17 file.NOI5TT
-rw-r--r-- 1 jens jens 207567 2007-06-24 18:17 file.IRF9TT
-rw-r--r-- 1 jens jens 186401 2007-06-24 18:17 fil...

[Jens Gersdorf (jens-gersdorf)]

Hi,

I just tried to analyse a little bit more and found some coincidence.

If nautilus is running when I try to export files to cd from f-spot, it is very very likely that I got the error.

The problem is that nautilus is always running in the ubuntu gnome session. I removed the nautilus process with

jens@toshiba:~$ gnome-session-remove nautilus

and after that, the cd export works as it should! I repeated this several times to be sure - and it is very clear. If I remove nautilus, it works, if I start nautilus again, it isn't working. I don't even have to shut down f-spot between removing and starting nautilus to see the difference.

So for me it seems to be clear that a running nautilus instance somehow is the reason for this bug.

Regards

Jens

[Jens Gersdorf (jens-gersdorf)]

Bug is still not solved

[Jens Gersdorf (jens-gersdorf)]

New Infos: I managed to install a debug version of the mapping-daemon (by the way, how should the orignal profile_log method work? I changed it to write to a file).

The interesting thing is that in the case the export fails, you can see that right after the operation MAPPING_PROTOCOL_OP_CREATE_FILE the mapping daemon receives a request MAPPING_PROTOCOL_OP_REMOVE_FILE to delete the file again. This MAPPING_PROTOCOL_OP_REMOVE_FILE is missing when the export succeeds (i.e. nautilus is not running).

So I think that somehow nautilus monitors the burn directory and immediately sends out a remove operation to the mapping daemon. That maybe also the solution why it sometimes works - it seems to be a race condition if nautilus is running during the export. Most of the time the remove operation is "fast enough" to let the export fail, but sometimes nautilus is to slow to send out the remove operation.

But it still has to be investigated why this remove operation is done by nautilus.

Regards

Jens

[Jens Gersdorf (jens-gersdorf)]

Hi,

I will attach new Logfiles - this time from the mapping daemon and from nautilus, which is utilizing libmapping.so. I finally realized that I can see the original debug log using strace.

The logfiles show the error case. I have enhanced the logfiles with timestamps to better see the sequence in the communication between nautilus and mapping-daemon. It seems that in do_read_directory nautilus gives the mapping-daemon to remove the file.

[Pedro Villavicencio (pedro)]

fixed upstream, please comment if you have the bug with newest version on jaunty.

[Launchpad Janitor (janitor)]

This bug was fixed in the package f-spot - 0.6.0.0-1~ubuntu1

---------------
f-spot (0.6.0.0-1~ubuntu1) karmic; urgency=low

  * Upload to Karmic from Debian's git VCS (LP: #410520)
  * New Upstream Version 0.6.0.0
   - no longer depends on libeog
   - fighting against deprecation, on the path to gnome3
   - new viewer widget
   - new widget showing folders organisation
   - new Preference dialog
   - db and config moved to .config (or whatever is pointed by xdg config)
   - tons of bugs fixed (really) (Closes: #534566, #449293, #479176, #305306,
     #537942, #418356)
     (LP: #77133, #290564, #298283, #379373, #405005, #116796, #178303,
     #355035, #368275)
   - updated translations
  * debian/control: Set Vcs-* to point to new Git locations
  * debian/control, debian/patches/*: Switch to quilt for patches, refresh all
    patches
  * debian/rules, debian/control: Rewrite in DH7 style (Closes: #531769)
  * debian/rules: Use ltmain-as-needed, modify LDFLAGS
  * debian/patches/99_ltmain_as-needed.dpatch: Drop, now applied in rules by
    copying from debian/
  * debian/patches/debian_unlink_nunit.dpatch: Drop, upstream now handles this
    case correctly by configure checks
  * debian/patches/debian_no_dup_app_icons.dpatch: Drop, upstream no longer
    ships svg icon
  * debian/patches/debian_link_2.0_profile_cairo.dpatch: Drop, fixed in mono
  * debian/patches/debian_dont_link_libmono.patch: Drop, ltmain-as-needed
    achieves this too
  * debian/patches/f-spot-import-gphoto.dpatch,
    debian/patches/svn-r4555_fix-crash-on-icon-size-change.dpatch,
    debian/patches/svn-r4545_locales-import.dpatch,
    debian/patches/debian_use_csc.dpatch,
    ubuntu_1024x600_CDExport.cs.dpatch,
    ubuntu_raw_escape_quote.dpatch (Closes: #481124),
    svn-display-sidebar.dpatch,
    svn-no-versionellipze.patch: Drop, fixed upstream
  * debian/control: Bump versions on a load of build-deps to match upstream
    configure checks. Also drop a load more build-deps that are no longer
    needed.
  * debian/{docs,menu,manpages}: Prefix with f-spot
  * debian/rules, debian/f-spot.install: Move DLLmap installation to
    f-spot.install instead of cp in rules
  * debian/gkeyfile-sharp.dll.config: Add, DLLImport was incorrect

 -- Iain Lane <email address hidden> Mon, 10 Aug 2009 17:42:29 +0100