GNOME Bugzilla – Bug 471887
Start Audio CD playback when Rhythmbox is already started
Last modified: 2007-11-07 00:35:20 UTC
+++ This bug was initially created as a clone of Bug #401091 +++ One should be able to launch rhythmbox with rhythmbox /dev/foocdrom and it should automatically play back the CD belonging to this device. <snip> We don't do anything with files passed on startup of the original instance. The attached patch allows the above to work, if we're already started up.
*** Bug 471888 has been marked as a duplicate of this bug. ***
Created attachment 94641 [details] [review] rhythmbox-play-audio-cds-remote.patch "rhythmbox /dev/hda" works now.
Looks like a reasonable approach to me. As far as I recall, you don't always get exactly the same path to the device (/dev/hdc vs /dev/cdrom, for example), depending on how you're invoking rhythmbox, so I think we'd need to resolve symlinks at some point. There's also the problem that the 'rhythmbox /dev/cdrom' process races against the running rhythmbox instance reading the tracks off the CD, so running 'rhythmbox /dev/cdrom' from gnome-volume-manager or whatever won't always work properly.
(In reply to comment #3) > Looks like a reasonable approach to me. As far as I recall, you don't always > get exactly the same path to the device (/dev/hdc vs /dev/cdrom, for example), > depending on how you're invoking rhythmbox, so I think we'd need to resolve > symlinks at some point. We match the URI to the source in the ::entry-parsed callback, the playlist parser has already done the work for us. > There's also the problem that the 'rhythmbox /dev/cdrom' process races against > the running rhythmbox instance reading the tracks off the CD, so running > 'rhythmbox /dev/cdrom' from gnome-volume-manager or whatever won't always work > properly. Does it use anything but HAL to get the device appearing in the source list? If so, we'd at least get the same info as on a new startup.
(In reply to comment #4) > (In reply to comment #3) > > Looks like a reasonable approach to me. As far as I recall, you don't always > > get exactly the same path to the device (/dev/hdc vs /dev/cdrom, for example), > > depending on how you're invoking rhythmbox, so I think we'd need to resolve > > symlinks at some point. > > We match the URI to the source in the ::entry-parsed callback, the playlist > parser has already done the work for us. On my system here, the CD drive is /dev/hdb; something (udev?) creates /dev/cdrom1 and several other symlinks to that device. ./test-parser file:///dev/hdb => cdda:///dev/hdb ./test-parser file:///dev/cdrom1 => cdda:///dev/cdrom1 Only one of those will match the source with the patch as is, but we should make them both work. > > There's also the problem that the 'rhythmbox /dev/cdrom' process races against > > the running rhythmbox instance reading the tracks off the CD, so running > > 'rhythmbox /dev/cdrom' from gnome-volume-manager or whatever won't always work > > properly. > > Does it use anything but HAL to get the device appearing in the source list? If > so, we'd at least get the same info as on a new startup. We should always get the same device name, but sometimes the 'play /dev/hdb' request might get processed before we've fully created the source.
(In reply to comment #5) <snip> > On my system here, the CD drive is /dev/hdb; something (udev?) creates > /dev/cdrom1 and several other symlinks to that device. > > ./test-parser file:///dev/hdb => cdda:///dev/hdb > ./test-parser file:///dev/cdrom1 => cdda:///dev/cdrom1 > > Only one of those will match the source with the patch as is, but we should > make them both work. I'll fix that to always point to the canonical device node. > > > There's also the problem that the 'rhythmbox /dev/cdrom' process races against > > > the running rhythmbox instance reading the tracks off the CD, so running > > > 'rhythmbox /dev/cdrom' from gnome-volume-manager or whatever won't always work > > > properly. > > > > Does it use anything but HAL to get the device appearing in the source list? If > > so, we'd at least get the same info as on a new startup. > > We should always get the same device name, but sometimes the 'play /dev/hdb' > request might get processed before we've fully created the source. How can we handle this? Maybe we could use the "pending entry", or a similar process?
(In reply to comment #6) > (In reply to comment #5) > <snip> > > On my system here, the CD drive is /dev/hdb; something (udev?) creates > > /dev/cdrom1 and several other symlinks to that device. > > > > ./test-parser file:///dev/hdb => cdda:///dev/hdb > > ./test-parser file:///dev/cdrom1 => cdda:///dev/cdrom1 > > > > Only one of those will match the source with the patch as is, but we should > > make them both work. > > I'll fix that to always point to the canonical device node. Fixed in gnome-2-20 and trunk. Was easy as we already resolved the symlink to find it in HAL. 2007-09-05 Bastien Nocera <hadess@hadess.net> * src/plparse/totem-disc.c: (totem_cd_detect_type_with_url): Use the canonical device when giving the cdda MRL * src/plparse/totem-pl-parser-media.c: (totem_pl_parser_add_block): Don't leak the error if there's a problem
Looks good to me. Maybe we can figure out a way to use this to select playlists using commandline args too.. playlist:name URIs?
2007-09-05 Bastien Nocera <hadess@hadess.net> * sources/rb-source.c: (rb_source_uri_is_source): * sources/rb-source.h: Add _uri_is_source, to allow sources to tell us that they are the URI that's being passed, as opposed to an item of the source being handled * shell/rb-shell.c: (rb_shell_class_init), (_scan_idle), (source_activated_cb), (rb_shell_activate_source), (handle_playlist_entry_cb), (rb_shell_load_uri): * shell/rb-shell.h: emit the removable_media_scan_finished signal when we're done scanning removable media on startup, Add rb_shell_activate_source to activate a particular source, When parsing URIs given on the command-line, check if a source is the URI and activate it * shell/main.c: (main), (dbus_load_uri), (removable_media_scan_finished), (local_load_uri): When starting up Rhythmbox, handle filenames passed after scanning for removable media has finished, fix a small memory leak in an error path * plugins/audiocd/rb-audiocd-source.c: (rb_audiocd_source_class_init), (impl_want_uri), (impl_uri_is_source), (impl_try_playlist): Implement want_uri, try_playlist and uri_is_source, Say we want the URI when the URI passed matches the device we handle (Closes: #471887) * plugins/iradio/rb-iradio-source.c: (rb_iradio_source_add_from_playlist): Don't use any fallback when parsing the playlist, we already fallback by adding the item to the source ourselves
*** Bug 331861 has been marked as a duplicate of this bug. ***