GNOME Bugzilla – Bug 526902
Unable to mount Audio Disc - Location is not mountable
Last modified: 2008-04-30 16:32:40 UTC
Insert Audio CD into Drive. Dialog containing the following text is displayed Unable to mount Audio Disc Location is not mountable
The function update_discs in ghalvolumemonitor.c calls g_hal_volume_new with is_mountable set to TRUE but subsequent attempt to mount the volume fails.
Is the cdda backend in your build?
No.
(In reply to comment #3) > No. That's why. Just include the cdda backend and this error will go away.
I built cdda backend. Now the error goes away. But there is still no CD disc icon appearing on the desktop, is this the expected behaviour?
okay. I got it. I changed that cdda.mount file to set AutoMount=true and that ion just appeared on the desktop. Should this be the right behavior, not? Since that was the old behaviour with gnome-vfs.
cdda mounts in gvfs are in many ways not different from kernel mounts (the notable one being that the code for driving the file system is in user space). Can you mount the audio disc from Nautilus manually? E.g. through the sidebar or from computer:///. Either way, nautilus is supposed to automount the volume when a) nautilus starts; and b) an audio disc is inserted. Does this not happen? The output of 'gvfs-mount -li' might be useful too. FWIW, this is what it looks like for me Drive(0): CD-RW/DVD-ROM Drive ids: hal-udi: '/org/freedesktop/Hal/devices/storage_model_CDRW/DVD_GCC4244' unix-device: '/dev/sr0' is_media_removable=1 has_media=1 is_media_check_automatic=1 can_poll_for_media=1 can_eject=1 Volume(0): Audio Disc ids: hal-udi: '/org/freedesktop/Hal/devices/volume_part_1_size_420249600' unix-device: '/dev/sr0' themed icons: [drive-optical-recorder] [drive-optical] [drive] can_mount=1 can_eject=1 Mount(0): Audio Disc -> cdda://sr0/ themed icons: [media-optical-audio] [media-optical] [media] can_unmount=1 can_eject=1
with some strange reason, it seems to work now regardless of setting in cdda.mount with gvfs-mount -li, I got, bash-3.2$ gvfs-mount -li Drive(0): CD-RW/DVD?RW Drive ids: hal-udi: '/org/freedesktop/Hal/devices/pci_0_0/pci_ide_1f_1/ide_0_0/sd0/sd0' unix-device: '/dev/dsk/c0t0d0s2' is_media_removable=1 has_media=1 is_media_check_automatic=1 can_poll_for_media=0 can_eject=1 Volume(0): Audio Disc ids: hal-udi: '/org/freedesktop/Hal/devices/pci_0_0/pci_ide_1f_1/ide_0_0/sd0/sd0/s2' unix-device: '/dev/dsk/c0t0d0s2' themed icons: [drive-optical-recorder] [drive-optical] [drive] can_mount=1 can_eject=1 Mount(0): Audio Disc -> cdda://c0t0d0s2/ themed icons: [media-optical-audio] [media-optical] [media] can_unmount=1 can_eject=1 I do have to modify the code slightly to make it works, though still not sure it is the right patch. --- gvfsbackendcdda.c.orig 2008-04-16 16:45:10.219644000 +0100 +++ gvfsbackendcdda.c 2008-04-16 16:46:21.112165000 +0100 @@ -268,7 +268,7 @@ return; } - cdda_backend->device_path = g_strdup_printf ("/dev/%s", host); + cdda_backend->device_path = g_strdup_printf ("/dev/dsk/%s", host); find_udi_for_device (cdda_backend); because the cdrom is mounted on /dev/dsk instead of /dev.
(In reply to comment #8) > --- gvfsbackendcdda.c.orig 2008-04-16 16:45:10.219644000 +0100 > +++ gvfsbackendcdda.c 2008-04-16 16:46:21.112165000 +0100 > @@ -268,7 +268,7 @@ > return; > } > > - cdda_backend->device_path = g_strdup_printf ("/dev/%s", host); > + cdda_backend->device_path = g_strdup_printf ("/dev/dsk/%s", host); > > find_udi_for_device (cdda_backend); > > because the cdrom is mounted on /dev/dsk instead of /dev. Yea, unfortunately I didn't find a way to pass the full device path in the URI because '/' isn't allowed there. So for the time being this would have to be a Solaris specific patch. I'll look into this for 2.24. So, anyway, with that patch cdda:// is working as expected on Solaris?
unfortunately, no quite. When I typed in cdda:// in nautilus I got an error: Couldn't display "cdda:///" Error No drive specified Please select another viewer and try again. If I specified cdda://c0t0d0s2/ in nautilus I got nautilus displaying the These files are on an audio CD (with Open CD Ripper) Clicking on that come up with Sound Juicer I guess these is the correct behaviour.
(In reply to comment #10) > unfortunately, no quite. > When I typed in cdda:// in nautilus > I got an error: > > Couldn't display "cdda:///" > Error No drive specified > Please select another viewer and try again. Right, that won't work. You may have multiple optical drives. > If I specified cdda://c0t0d0s2/ in nautilus > I got nautilus displaying the > These files are on an audio CD (with Open CD Ripper) > Clicking on that come up with Sound Juicer > > I guess these is the correct behaviour. Right. Except that you never will have to type anything in; if there's an audio disc there will be a GVolume and double clicking that will start the gvfs cdda backend.
Got you :) When I double clik on the Audio disc icon on the desktop, the nautilus file browsing dialog come up. When I right click on it, it shows that I can Open Browse Folder Open with CD Ripper Open With Rhythmbox Music Player ... So What I really need to do is to change mime database such that CD Ripper will be launched instead of file browser or is this controlled by gvfs cdda backend.
(In reply to comment #12) > So What I really need to do is to change mime database such that CD Ripper will > be launched instead of file browser or is this controlled by gvfs cdda backend. JFYI, we decided upstream that the default action for double clicking is to open a folder. Users can launch the preferred application for x-content/audio-cdda via the blue cluebar in the folder window. Either way, normal users won't be double clickin icons as the cdda fs will be automount. And once automounted the autorun mechanism in Nautilus will kick in (see the Media tab in the Nautilus preference capplet) and open the cd ripper anyway. You are however free to patch the sources to make it act like you want.
I would like to repoen this as I would like to have a gvfsbackendcdda which does not depend on libcdio. Is there a program which I can use as a specification for how gvfsbackendcdda should behave?
(In reply to comment #14) > I would like to repoen this as I would like to have a gvfsbackendcdda which > does not depend on libcdio. > > Is there a program which I can use as a specification for how gvfsbackendcdda > should behave? > I'm not sure repurposing this bug for writing a replacement is appropriate. What exactly is the problem with depending on libcdio? AFAIK it works fine on Solaris at least according to http://mail.gnome.org/archives/gnome-vfs-list/2006-May/msg00030.html
The problem with libcdio is that it is not delivered on Solaris because of licensing and copyright concerns.
(In reply to comment #16) > The problem with libcdio is that it is not delivered on Solaris because of > licensing and copyright concerns. Can you elaborate on this? Are your concerns something that might affect other vendors too? Thanks.
David, Our primary reason for not wanting to ship libcdio is that it is a GPL library, and we feel it is better to avoid shipping GPL'ed libraries unless really necessary. You point to my email from the May 2006 gnome-vfs alias. At that time I was excited about libcdio since it seemed to make GStreamer work with CDDA on Solaris, and thus made programs like sound-juicer work. However, a while later I realized that it is not appropriate to link a GPL library into the LGPL GStreamer framework. At Sun, we would like GStreamer to remain LGPL so that 3rd parties can consider writing GStreamer based programs without worry that their programs will need to be GPL. Once we realized libcdio had this licensing issue, we ripped libcdio out of Solaris and wrote a with a simple ioctl-based GStreamer CDDA plugin under the more friendly LGPL license. You can refer to bug #529741 if you want to read more about this. Since we addressed the GStreamer CDDA issue in this way, the only other thing in the GNOME stack which seems to depend on libcdio is the gvfs CDDA plugin. By itself, it does not seem enough to really warrant adding libcdio to Solaris. It might make more sense for us to hack it to use the same CDDA ioctl code that we use in GStreamer (as discussed in bug #529741) if there is really a need for the gvfs CDDA plugin to work on Solaris. Joerg Schilling, here at Sun, has made assertions about quality problems with libcdio and highlights copyright issues as further reasons not to integrate it into Solaris. I am not sure if his statements are true, or if he is making a big fuss over small issues. Note Joerg maintains a competing project called cdda2wav, so some of his criticism about libcdio might just be his way of expressing enthusiasm about how cdda2wav is better than libcdio. I am not sure. Personally I would say that the GPL reason alone is reason-enough not to ship libcdio on Solaris. That said, the fact that Joerg has raised these copyright concerns will make our legal review process to include libcdio more time-consuming if we ever decide to re-introduce libcdio into Solaris. --- Joerg has stated the following: The libcdio maintainer (Rocky Bernstein) has no authority to change the license as he is not the author (although he claims to be the author of "libcdio"). The audio part of libcdio has been made by minor modifications on the "cdparanoia" program. This program is mainly made of: - a 1997 GPld version of cdda2wav from Heiko Eißfeldt - the paranoia code from Monty. The license for cda2wav may only be changed by Heiko Eißfeldt The license for the paranoia code may only be changed by Monty. The Libcdio paranoia code has been changed from GPLv2 only to GPLv2 or any later without permission from Monty. --- Even if we ignore license problems from libcdio, libcdio introduces a privilege problem. It may be unknown, but Linux-2.4 cannot "support" all these recent "development" based on tattered code originated from cdrtools. At the transition time from Linux-2.4 to 2.5, an inexperienced person changed the code without thinking about results. You then could send any SCSI command to any device you may open readonly (usually true for CD-ROMs). At that time, people started to tatter the cdrtools source and to create questionable libraries that all depend on the related Linux security bug. In summer 2004 this was discovered and instead of fixing the bug introduced by the inexperienced person, Torvalds decided to allow a selected number of SCSI commands to be issued without any special privileges. No other OS implements similar behavior and for this reason, these "libs" are all non-portable. Software like GNONE, that depends on these libs cannot be made cleanly portable anymore. --- Joerg's Sun email is Joerg.Schilling@Sun.COM if you want to discuss his concerns about libcdio further with him.
Hi, Keep in mind that gvfs backend runs as a separate processes meaning that no application are ever linking to it. See also the notes about LGPVv2+/GPLv2+ in the daemon/gvfsbackendcdda.c file. (In reply to comment #18) > Since we addressed the GStreamer CDDA issue in this way, the only other thing > in the GNOME stack which seems to depend on libcdio is the gvfs CDDA plugin. > By itself, it does not seem enough to really warrant adding libcdio to Solaris. > It might make more sense for us to hack it to use the same CDDA ioctl code that > we use in GStreamer (as discussed in bug #529741) if there is really a need > for the gvfs CDDA plugin to work on Solaris. I'm not opposed to taking patches for daemon/gvfsbackendcdda.c to support your CDDA ioctl based library. Just use #ifdef. But please file a new bug about this; it's not appropriate to use this bug for it. > Joerg's Sun email is Joerg.Schilling@Sun.COM if you want to discuss his > concerns about libcdio further with him. I have absolutely no desire to interact with Joerg.
Yes, I realize that gvfs is GPL, so linking in libcdio is not a problem for gvfs. Adding libcdio to meet the needs is something we are considering. However, adding a GPL library is not desirable, so making the gvfs CDDA plugin work with a CDDA ioctl based approach (or some other approach that doesn't involve a GPL library) would likely be preferred. Another thing to consider is that I have heard from the GStreamer team that the libcdparanoia library is going to relicense as LGPL, so supporting that in gvfs might be a nicer solution. libcdparanoia doesn't yet work on Solaris, but I think Sun would be interested in fixing libcdparanoia if they do this, since it's licensing would be better. If we pursue modifying the gvfs backend to use libcdparanoia and/or an ioctl based CDDA backend, I agree we should open a new bug report and work with you to get this upstream.
> Another thing to consider is that I have heard from the GStreamer team that the > libcdparanoia library is going to relicense as LGPL, so supporting that in gvfs > might be a nicer solution. Just FYI, and this is coming from me as the author/maintainer of the gvfs cdda backend, this won't happen until libcdparanoia stops using O_EXCL on Linux. This is especially a problem since libcdparanoia is trying to be "helpful" and keep opening the device some twenty times, sleeping one second inbetween, if opening the device fails. Totally screwing the application trying to use this library (e.g. sound-juicer can't handle expose events). While that might be fine for a commandline app to do (e.g. cdparanoia(1) on which libcdparanoia is based), it's very bad form for a library to impose such policy and do things behinds the back of an application. Ideally libcdparanoia would just take an fd for the device given to it by the application and let the application itself sort out error handling. So things like that would have to be fixed before considering moving away from libcdio. (IMO it's a bug in libcdparanoia that it opens the device using O_EXCL; it prevents other apps from using the device (including mounting mixed discs) and, at least, recent Linux kernels (2.6.x with x being a single digit) have no problem whatsoever with multiple openers (of course burning/fixating the disc will be a problem but the CDDA backend will never ever run unless there's audio on the disc).