GNOME Bugzilla – Bug 679821
gvfs 0.13.1+ breaks apps using brasero-media
Last modified: 2012-07-30 18:06:37 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).
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.
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 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.
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).
(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.
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
@ 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.
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.
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.
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
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...
(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.
*** Bug 680615 has been marked as a duplicate of this bug. ***