GNOME Bugzilla – Bug 325602
Add support for mass storage audio players
Last modified: 2006-01-16 13:45:58 UTC
It would be nice to support audio players other than iPods as well. Bug 149716 is for iRiver support, this one is for generic mass-storage players.
Created attachment 56702 [details] [review] patch Patch to add support for mass-storage players
*** Bug 325601 has been marked as a duplicate of this bug. ***
Created attachment 56704 [details] tarball New files
Compilation failure against a clean cvs co. rb-audiocd-source.c: In function 'rb_audiocd_source_new': rb-audiocd-source.c:164: warning: 'device_path' is used uninitialized in this function
Created attachment 56711 [details] [review] fixed patch Oops. I wonder why I didn't get that here.
Hi, Tried with a small, quite cheap, MP3-player named INO 3(I). This player is not recognised by RB. It's a HAL issue beqause the device hasn't the capabilities of portable_audio_player, only storage and block. /J
I know Aaron Bock (Banshee's maintainer) was getting people to send in the data on players, so that the FDI files could be updated. If you wanted you could probably add your own entry to the file (which is /usr/share/hal/fdi/information/10freedesktop/10-usb-music-players.fdi on my machine). Most "generic" players will have the entry inside the <match key="@storage.physical_device:info.bus" string="usb"> section; you could probably copy one of the existing ones and change the vendor and product ids (which you can get from hal-device-manager)
Created attachment 56748 [details] updated tarball A few minor fixes. It now walks up the device tree looking for something with the portable_audio_player capability, which will work if the mass-storage volume is nto a direct child of the player.
Created attachment 56807 [details] [review] updated patch Fixes a compilation issue, and allows the disabling of HAL usage. The generic player source is added without HAL support, but won't actually do anything as RB can't detect players; this is because we may want to add other methods for detection. Having some method of manually marking a device/volume as "interesting" would be handy, to support players that HAL doesn't (yet) know about or volumes that aren't actually players (e.g. flash cards). Jonathan suggested on IRC that the presence of a hidden file in the root of the volume would be a possible method to mark this.
Created attachment 56901 [details] updated tarball This fixes a few issues, and also add support for using devices not recognised by HAL. You can make Rhythmbox treat any volume as a "generic audio player" but putting a file called ".is_audio_player" in the root directory of the volume.
Created attachment 56902 [details] [review] updated patch
The latest patch works for me (using the tag file and my generic flash card device), but I get the following message twice when I plug it in: 20720: arguments to dbus_move_error() were incorrect, assertion "(dest) == NULL || !dbus_error_is_set ((dest))" failed in file dbus-errors.c line 243. This is normally a bug in some application using the D-BUS library. and this when I right-click on it in the source list: (rhythmbox:20720): Gtk-CRITICAL **: gtk_menu_popup: assertion `GTK_IS_MENU (menu)' failed
Created attachment 56952 [details] [review] newer patch This fixes the menu issue. It currently segfaults if the player is removed while we are loading tracks:
+ Trace 65031
Created attachment 57386 [details] [review] updated patch This version fixes the dbus issue from comment 12. The problem I mentioned in comment 13 seems to have disappeared too.
Created attachment 57387 [details] updated tarball
Also works with my shiny new iriver t30 (usb mass storage version) after I added a few rules to a .fdi file for it.
Committed to cvs.