GNOME Bugzilla – Bug 530651
Mounted DVD ISO doesn't offer playback
Last modified: 2018-09-21 16:21:48 UTC
1. Browse a remote folder 2. See a DVD ISO 3. Mount it using the "Archive mounter" 4. Open new mount that appeared on the desktop 5. See that it doesn't offer to launch Totem to play DVD
This would probably be because your account doesn't have access to the /dev/fuse device (needed for opening remote urls as local folders), Totem's .desktop file must mark it as only handling local urls and the "Archive Mounter" must have a .desktop that specifies it can use remote URLs. It's a little bit a Nautilus bug, as there's no user notification that this is the case, but the big problem is distro-specific, as Nautilus really needs distros to give /dev/fuse access to all Nautilus users for everything to go smoothly. Does giving yourself access to /dev/fuse fix this? Or is this some other issue?
It has nothing to do with fuse. "gvfs-mount -li" doesn't even show any x_content_types output for that mount. Mount(0): test.iso -> archive://file%3A%2F%2F%2Fhome%2Fdata%2Ftest.iso/ themed icons: [drive-removable-media] [drive-removable] [drive] can_unmount=1 can_eject=0 The media has matching files. totem-pl-parser (using g_content_type_guess_for_tree) works fine: $ ./disc-test ~/.gvfs/test.iso/ /home/hadess/.gvfs/test.iso/ contains a DVD URL for directory is dvd:///home/hadess/.gvfs/test.iso/ But g_mount_guess_content_type() doesn't seem to work.
Thanks for the analysis. Forwarding to GVFS.
Sorry for the earlier rather random guess (blaming lack of sleep around the time I submitted that particular comment). Having dug through gvfs for a bit, I can narrow this down to being that the archive backend for gvfs doesn't call g_vfs_backend_set_x_content_types - hence the lack of x_content_types, and why g_mount_guess_content_type fails (it relies on the x_content_types). I've just confirmed this against the 2008-09-09 SVN head for gvfs.
No, each backend shouldn't have to do that themselves. First, because it's not changeable. So that works fine for read-only media (an audio CD will always be x-content/cdda, or whatever), and a music player will always be a music player. But files on other mounts should still have g_content_type_guess_for_tree() called (otherwise it will still think it's a DVD, even if you remove the DVD files). I guess it would also fail if you had a DVD or a DCIM directory on a flash drive, although I haven't tested it.
There's currently no good way to do this for daemon mounts; right now the only utility is is to set it at mount initialization time via g_vfs_backend_set_x_content_types () but that's suboptimal. We really just want to implement g_daemon_mount_guess_content_type() g_daemon_mount_guess_content_type_sync() *properly* in client/gdaemonmount.c and forward that method to the mount backend. Then the default implementation in GVfsBackend will use this utility g_content_type_guess_for_tree() http://library.gnome.org/devel/gio/unstable/gio-GContentType.html#g-content-type-guess-for-tree and things like the cdda and gphoto2 backends can override this to force e.g. x-content/cdda or x-content/image-dcf. With this we can probably also delete g_vfs_backend_set_x_content_types (). There's a bit of an issue here - for slow network mounts we really don't want any sniffing done at all; so perhaps the default impl in GVfsBackend should just return the empty list. And then you can override it for things like the archive backend. Makes sense?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/48.