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 679821 - gvfs 0.13.1+ breaks apps using brasero-media
gvfs 0.13.1+ breaks apps using brasero-media
Status: RESOLVED FIXED
Product: gvfs
Classification: Core
Component: cdda backend
1.13.x
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
: 680615 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-07-12 19:48 UTC by Gert Kulyk
Modified: 2012-07-30 18:06 UTC
See Also:
GNOME target: 3.6
GNOME version: ---


Attachments
Testcase (652 bytes, text/plain)
2012-07-27 14:39 UTC, Gert Kulyk
Details

Description Gert Kulyk 2012-07-12 19:48:49 UTC
Since I switched from gvfs 1.12.x to 1.13.x, every time I'm inserting an audio cd it is not getting recognized correctly, causing e.g. that gnome-shell is not offering an action after cd insertion or worse, like in sound-juicer, that the cd drive isn't available to apps at all. All other media types (I tested data cds, DVD data and video) are working fine, external media like flashdrives, too.

It seems like it has something to do with the gdbus port, because all commits before 8315eaf (the actual port), are working fine. 

Unfortunately I did not find any useful hint in the logs what is actually going wrong, here is what dmesg was logging when I was inserting an ordinary audio cd
 that used to work with previous gvfs releases:

[  244.263760] sr 0:0:1:0: [sr0]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  244.263771] sr 0:0:1:0: [sr0]  Sense Key : Illegal Request [current] 
[  244.263779] Info fld=0x10, ILI
[  244.263783] sr 0:0:1:0: [sr0]  Add. Sense: Illegal mode for this track
[  244.263797] sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 00 00 10 00 00 01 00
[  244.263809] end_request: I/O error, dev sr0, sector 64
[  244.274113] sr 0:0:1:0: [sr0]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  244.274121] sr 0:0:1:0: [sr0]  Sense Key : Illegal Request [current] 
[  244.274128] Info fld=0x100, ILI
[  244.274131] sr 0:0:1:0: [sr0]  Add. Sense: Illegal mode for this track
[  244.274141] sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 00 01 00 00 00 01 00
[  244.274153] end_request: I/O error, dev sr0, sector 1024
[  244.274257] UDF-fs: error (device sr0): udf_read_tagged: read failed, block=256, location=256
[...]

Why there is an udf fs probed, no idea (no data tracks on the given cd, only plain cd audio).
Comment 1 Bastien Nocera 2012-07-12 20:33:03 UTC
Pretty certain this has nothing to do with gvfs itself. You'll need to check the build options you're using, my guess is either udisks2 support, or the libcdio support (for CD-Text) is causing this.
Comment 2 Gert Kulyk 2012-07-12 20:37:30 UTC
It's possible that it is related to udisks2 (recent git snapshot) and / or libcdio (0.83). But why gvfs prior to commit 8315eaf is working like it should? (I recompiled it again after reporting this and it just works).
Comment 3 Bastien Nocera 2012-07-12 20:49:00 UTC
Is it recognised by the gvfs disk monitors? Run gvfs-mount -li
Or is it recognised properly, but gvfsd-cdda craps itself. If the latter, you can kill the running version, and launch "gvfsd-cdda host=sr0" and see whether there are any errors.
Comment 4 Gert Kulyk 2012-07-12 21:22:44 UTC
Well, it seems like it is recognized. gvfs-mount -li gives the following output:

Drive(1): CD/DVD Drive
  Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
  ids:
   unix-device: '/dev/sr0'
  themed icons:  [drive-optical]  [drive]
  is_media_removable=1
  has_media=1
  is_media_check_automatic=1
  can_poll_for_media=0
  can_eject=1
  can_start=0
  can_stop=0
  start_stop_type=unknown
  sort_key=00coldplug/11removable/sr0
  Volume(0): Audio-CD
    Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
    ids:
     class: 'device'
     unix-device: '/dev/sr0'
    activation_root=cdda://sr0/
    themed icons:  [media-optical-cd-rom]  [media-optical-cd]  [media-optical]  [media]
    can_mount=1
    can_eject=1
    should_automount=1
    sort_key=gvfs.time_detected_usec.1342127611874017
    Mount(0): Audio-CD -> cdda://sr0/
      Type: GProxyShadowMount (GProxyVolumeMonitorUDisks2)
      default_location=cdda://sr0/
      themed icons:  [media-optical-cd-rom]  [media-optical-cd]  [media-optical]  [media]
      x_content_types: x-content/audio-cdda
      can_unmount=1
      can_eject=1
      is_shadowed=0
Mount(0): Audio-CD -> cdda://sr0/
  Type: GDaemonMount
  default_location=cdda://sr0/
  themed icons:  [media-optical-audio]  [media-optical]  [media]
  x_content_types: x-content/audio-cdda
  can_unmount=1
  can_eject=0
  is_shadowed=1

The problem only is, that no other app than nautilus can use it. Does the gdbus port need an adjustment in other apps (e.g. gnome-shell?) The shell e.g. produces errors like this:

 JS LOG: Cannot find connection for active (or connection cannot be read)
 JS LOG: Unable to mount volume Audio-CD: Gio.IOErrorEnum: DBus error org.freedesktop.DBus.Error.InvalidArgs: Mountpoint Already registered

Sound-juicer e.g. claims not find a cddrive at all. (both apps are working with the earlier mentioned pre 0.13.1 snapshot).
Comment 5 Tomas Bzatek 2012-07-13 12:08:28 UTC
(In reply to comment #2)
> It's possible that it is related to udisks2 (recent git snapshot) and / or
> libcdio (0.83). But why gvfs prior to commit 8315eaf is working like it should?
> (I recompiled it again after reporting this and it just works).

Is there really a change in behaviour before and right after, i.e. commits cc34b3 vs. 8315ea? The gdbus port was mostly about GProxyVolumeMonitor (and metadata, but that's not relevant here), the particular volume monitors were left untouched. But yeah, there could be a problem in between but certainly not in the way how media are detected.

Comparing gvfs-mount -li output before and after would be great to have. It will show you which volume monitoring backend is active, if there was a switch between gdu and udisk2 or not.

I also wonder why there are two Mount(0) instances listed in comment 4.

(In reply to comment #4)
>  JS LOG: Unable to mount volume Audio-CD: Gio.IOErrorEnum: DBus error
> org.freedesktop.DBus.Error.InvalidArgs: Mountpoint Already registered
> 

That could be another problem, related to my last comment.
Comment 6 Tomas Bzatek 2012-07-13 12:17:04 UTC
FYI, just tested freshly burned Audio CD on CD-RW medium and it works as expected, including the CDDA backend. Showing the same extra mount for Audio CD (probably harmless?).

gvfs-1.13.1
udisks-1.97.0
Comment 7 Gert Kulyk 2012-07-13 20:20:33 UTC
@ Tomas
This is the output of gvfs-mount -li with 0.13.0 cc34b37. In comment 4 you'll find the output with 0.13.2 1592330. 

Drive(1): CD/DVD Drive
  Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
  ids:
   unix-device: '/dev/sr0'
  themed icons:  [drive-optical]  [drive]
  is_media_removable=1
  has_media=1
  is_media_check_automatic=1
  can_poll_for_media=0
  can_eject=1
  can_start=0
  can_stop=0
  start_stop_type=unknown
  sort_key=00coldplug/11removable/sr0
  Volume(0): Audio-CD
    Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
    ids:
     class: 'device'
     unix-device: '/dev/sr0'
    activation_root=cdda://sr0/
    themed icons:  [media-optical-cd-rom]  [media-optical-cd]  [media-optical]  [media]
    can_mount=1
    can_eject=1
    should_automount=1
    sort_key=gvfs.time_detected_usec.1342210310452924
    Mount(0): Audio-CD -> cdda://sr0/
      Type: GProxyShadowMount (GProxyVolumeMonitorUDisks2)
      default_location=cdda://sr0/
      themed icons:  [media-optical-cd-rom]  [media-optical-cd]  [media-optical]  [media]
      x_content_types: x-content/audio-cdda
      can_unmount=1
      can_eject=1
      is_shadowed=0
Mount(0): Audio-CD -> cdda://sr0/
  Type: GDaemonMount
  default_location=cdda://sr0/
  themed icons:  [media-optical-audio]  [media-optical]  [media]
  x_content_types: x-content/audio-cdda
  can_unmount=1
  can_eject=0
  is_shadowed=1

So there is no difference in the outputs, but with the older version e.g. sound-juicer finds the cd-device while with the newer one it doesn't.
Comment 8 Gert Kulyk 2012-07-15 08:57:17 UTC
Changed title as it seems that in general gvfsd-cdda is working. The problem is, that every app that is using libbrasero-media (sound-juicer, rhythmbox, goobox) is no longer able to find any drives after upgrading gvfs (gnome-shell automount doesn't work for audio-cds either, but this seems to be a different issue). Please tell me if you need specific logs.
Comment 9 Gert Kulyk 2012-07-27 14:39:46 UTC
Created attachment 219742 [details]
Testcase

I'm attaching a test case similar to the code used in libbrasero-media for drive and volume detection. Simply compile it using:

gcc -o probe-drive-and-media $(pkg-config --libs --cflags glib-2.0 gio-2.0) probe-drive-and-media.c

and if you run it you'll see that neither drives nor volumes are found if gvfs 1.13.1+ is active.

What seems to be broken since the gdbus port of gvfs is something like:

drives = g_volume_monitor_get_connected_drives (g_volume_monitor_get ());

or

volumes = g_volume_monitor_get_volumes (g_volume_monitor_get ());

when gvfsd is running.
Comment 10 Tomas Bzatek 2012-07-30 14:04:09 UTC
Right, with the help of your reproducer I was able to locate the problem. We were doing async I/O in GProxyVolumeMonitor constructor and were waiting for async reply to start getting information. Everything was working fine in gvfs-mount since it granted half a second delay for proper object discovery on startup: http://git.gnome.org/browse/gvfs/tree/programs/gvfs-mount.c#n694


commit ee29ebe3a7af92984ca395e8f1d110f5a52716a1
Author: Tomas Bzatek <tbzatek@redhat.com>
Date:   Mon Jul 30 15:52:29 2012 +0200

    proxyvolumemonitor: Use GDBusProxy's name owner change notification
    
    Some GVolumeMonitor users don't run mainloop thus we're not able
    to do any async I/O. Using GDBusProxy name owner monitoring should
    get us the same functionality as separate g_bus_watch_name() call
    with the benefit of not doing any async I/O in GProxyVolumeMonitor
    constructor. This way we could populate volume monitor objects
    during initialization.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=679821
Comment 11 Gert Kulyk 2012-07-30 14:39:44 UTC
Thank you for fixing this. Now I can use the libbrasero-media based apps again.

Now there is another issue with audio cds: When having a fstab entry for the cdrom drive, the testapp shows up 2 volumes (nautilus in the sidebar two drive entries, Audio-CD and eg. cdrom0), but this is maybe another issue...
Comment 12 Tomas Bzatek 2012-07-30 14:42:21 UTC
(In reply to comment #11)
> Thank you for fixing this. Now I can use the libbrasero-media based apps again.
Cool!

> Now there is another issue with audio cds: When having a fstab entry for the
> cdrom drive, the testapp shows up 2 volumes (nautilus in the sidebar two drive
> entries, Audio-CD and eg. cdrom0), but this is maybe another issue...

Yes, please open a separate bugreport and attach output of `udisks --dump` as well as `gvfs-mount -li`. This may be a problem in the udisks2 volume monitor.
Comment 13 Gert Kulyk 2012-07-30 18:06:37 UTC
*** Bug 680615 has been marked as a duplicate of this bug. ***