GNOME Bugzilla – Bug 76528
Allow adding / removing songs from portable MP3 players
Last modified: 2007-03-26 12:26:54 UTC
Yes something like http://gtkpod.sourceforge.net/ as part of the rhythmbox package would be really cool.
Are we talking about ipods or about mp3 players in general?
I would love support for my Yepp mp3 player, Its just a mass storage device mounted on /mnt/yepp
I use a Creative Muvo which mounts as a fat16 mass storage device, mounted on /mnt/muvo. I don't know that there's a convention for these device locations though.
I think implementing D-BUS / HAL support should allow to detect any mounted / new plugged-in players or mass-storage devices with audio data.
One extra feature along these lines that I think would be great: Just supporting adding/removal of songs straight from the library seems like it's going one step to short (plenty of options for this) what I would love to see is the ability to: Select songs either by hand, or a random number (the AutoFill thing that iTunes is doing seems very cool btw) Downsample those songs to a lower bitrate before storing them on the portable player. (I'm sure I'm not the only one that likes to have all their music archived at a higher bitrate than than really strictly need for a portable player?) This would mean there'd need to be two seperate databases, one for the pc music and one for the portable which would add complexity, (and drastically slow down transfers too) but it'd be very cool. I _sort of_ do this by hand with a couple of scripts already, but it'd be very nice to have it working with rhythmbox! And it'd be a point of difference, something Rhythmbox could do that I haven't seen on any other jukebox software....
Being able to specify a directory (as a device in the leftmost window), then highlight songs and copy them there would be nice. I'd like to be able to set a format for that device and then have it automatically encode/downsaple to that format. ie FLAC to 192 CBR MP3. This would work for mass storage type devices and sharing music (make a dir on the hard drive and quickly encode). Right now I have a FLAC to MP3 shell script to do that.
this would be awesome, GUI-wise, it would be just a source you add to the left-panel (besides library, radio, ipod), or maybe a replacement for "ipod", and make it "portable player".
Some of this has now been done in bug #325602 which is now in CVS. If this bug addresses your needs, please close this bug. Switch component to "Removable Media".
Created attachment 70799 [details] [review] first patch This seems to work OK for me. I'd like to have a bit more control over the directory structure on the device, though.
Created attachment 70806 [details] [review] additional hackery maps some gstreamer media types to mime types, mostly so you can transfer mp3s
For reference, what Banshee does with folder_depth >= 3 is used folders with the start of the Artist name, e.g. G/Gr/.../Green Day/Dookie/. We probably want to add some more RBEncoder API for passing multiple mime-types. If the current mime-type is in the list then just copying, and if not transcoding to the first type in the list that there is an encoding profile for.
Created attachment 75715 [details] [review] updated patch Updated for changes in cvs
Created attachment 77116 [details] [review] add some multiple-mime support This adds support to RBEncoder for passing multiple mime types, and makes use of it in the generic player source. One thing that is still an issue is that when the source needs to determine the file name, it doesn't know what format it's being transcoded to, so doesn't know what extension to use.
Created attachment 78114 [details] [review] better patch This adds a new RBEncoder function that indicates which is the "best" mimetype to use out of a given set, and the appropriate file extension. This patch works pretty well with my ipod (both ipod plugin and generic-player plugin), with one exception: we currently detect MP3s as application/x-id3 not audio/mpeg so it always transcodes them from mp3 to mp3.
Hmm, I just tried to drag and and drop an mp3 to the generic player, got this crash: System: Linux 2.6.18-1.2849_2.fc6.cubbi_suspend2 #1 SMP Fri Dec 1 20:59:23 PST 2006 i686 X Vendor: The X.Org Foundation X Vendor Release: 70101000 Selinux: No Accessibility: Disabled ----------- .xsession-errors (283686 sec old) --------------------- localuser:alex being added to access control list warning: /etc/X11/xinit/xinitrc.d/sonypid does not end in .sh extension, ignoring -------------------------------------------------- Memory status: size: 152207360 vsize: 0 resident: 152207360 share: 0 rss: 33779712 rss_rlim: 0 CPU usage: start_time: 1165824053 rtime: 0 utime: 353 stime: 0 cutime:333 cstime: 0 timeout: 20 it_real_value: 0 frequency: 2 Backtrace was generated from '/home/alex/bin/rhythmbox' Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1208944176 (LWP 19481)] [New Thread -1272489072 (LWP 19491)] 0x00f83402 in __kernel_vsyscall ()
+ Trace 93229
Thread 1 (Thread -1208944176 (LWP 19481))
That crash can be fixed by changing "*mime != NULL" to "mime && *mime != NULL" in the for loop condition in impl_get_mime_types (rb-generic-player-source.c)
FYI I downloaded the sources from gnome ftp: http://ftp.gnome.org/pub/GNOME/sources/rhythmbox/0.9/ latest patch does not work fully with version 0.9.6 although rb-0.9.6 was online before this patch: --------------------------- Hunk #6 FAILED at 945. Hunk #7 succeeded at 1221 (offset 33 lines). 1 out of 7 hunks FAILED -- saving rejects to file sources/rb-ipod-source.c.rej --------------------------- and with 0.9.7 is even worse and of course it does not compile: --------------------------- patching file backends/rb-encoder.c patching file backends/rb-encoder.h patching file backends/gstreamer/rb-encoder-gst.c Hunk #1 FAILED at 67. Hunk #2 succeeded at 81 (offset 1 line). Hunk #4 FAILED at 254. Hunk #5 FAILED at 277. Hunk #6 succeeded at 642 (offset 15 lines). Hunk #8 succeeded at 874 (offset 15 lines). Hunk #10 succeeded at 975 (offset 15 lines). Hunk #11 FAILED at 983. Hunk #12 FAILED at 1002. Hunk #13 succeeded at 1035 (offset 4 lines). 5 out of 13 hunks FAILED -- saving rejects to file backends/gstreamer/rb-encoder-gst.c.rej patching file bindings/python/rb.defs patching file lib/rb-util.c Hunk #1 succeeded at 872 (offset 14 lines). patching file lib/rb-util.h patching file plugins/generic-player/rb-generic-player-source.c patching file plugins/generic-player/rb-generic-player-source.h patching file shell/rb-removable-media-manager.c patching file shell/rb-removable-media-manager.h patching file sources/rb-ipod-source.c Hunk #4 succeeded at 911 (offset 5 lines). Hunk #6 FAILED at 946. Hunk #7 succeeded at 1195 (offset 7 lines). 1 out of 7 hunks FAILED -- saving rejects to file sources/rb-ipod-source.c.rej patching file sources/rb-removable-media-source.c patching file sources/rb-removable-media-source.h ------------------------
Created attachment 78852 [details] [review] updated to current cvs
While this patch no longer crashes, when I drag an mp3 from the Library to a generic player, nothing is transferred and I see the following warning on the console: (rhythmbox:31193): Rhythmbox-CRITICAL **: rb_encoder_gst_get_preferred_mimetype: assertion `mime_types != NULL' failed
It compiles great with 0.9.7, but my (no-name chinese) player is not visible in rhythmbox. I saw that plugin name is "Portable Players - iPod". shouldn't this plugin/patch work with all mp3-players, not just with iPod?
sorry, my mistake ... I read a little bit, learned a lot about HAL and added my player's fdi informations. The player is recognized and I am now able to play and transfer files to my player. I have a few objections/questions: 1. rhythmbox does not copy files to the player, but encodes the files before copying. it converts my mp3 files to ogg (because that profile is selected and it is pretty time consuming. why does it encode files without asking? can we somehow avoid this behavior? 2. RB always creates the following directory structure on the the player: "Artist/Album/" although I selected "Artist-Album" 3. It always asks do I want to overwrite the file which is existing on the player. It would be better to be able to set default option, because nobody wants to click 30 times on "No". and when I click on "No", RB shows an error: ----------- Could not open vfs file "file://..../myFile.ogg" for writing: file exists" ----------- although it should not write anything. clicking on "Yes" encodes the file again without errors. 4. RB doesn't remember when the "browse" area is open for the player. I have to open it every time I connect my player to my computer 5. when I delete a file directly from mp3 player, it does not delete it, but it just removes it from the list. manual "sync" does not help
sources/rb-ipod-source.c has moved to plugins/ipod/rb-ipod-source.c otherwise the patch works great here. Only issue is that encodes my mp3's to mp3, a bit unnecessary!
I don't think that's unnecessary. My mp3's I have on my harddisk are of 192 KBit or more, and the ones I play on my MP3 player don't have to be of that high quality since you also have a lot of enviroment noise... If they would be copied with 192 Kbit, a lot of space would be wasted (no, I don't have the luxary to buy an mp3 player with a few gigabyte of space, I only have 128 MB, so every byte counts :) )
Created attachment 81424 [details] [review] updated patch Update to current svn, and fix a number of fairly big (over half a meg per track copied) memory leaks. (In reply to comment #23) > otherwise the patch works great here. Only issue is that encodes my mp3's to > mp3, a bit unnecessary! (In reply to comment #24) > I don't think that's unnecessary. My mp3's I have on my harddisk are of 192 > KBit or more, and the ones I play on my MP3 player don't have to be of that > high quality since you also have a lot of enviroment noise... If they would be > copied with 192 Kbit, a lot of space would be wasted (no, I don't have the > luxary to buy an mp3 player with a few gigabyte of space, I only have 128 MB, > so every byte counts :) ) This is probably something we should let people change on a per-player basis. Since whether to re-encode at a lower bitrate really depends on how much space is on your player. This could probably go in a future dialog which lets you look at/change the properties of your player, along with other things like how much space to use up for automagically synced music and what to fill it with.
There is a crasher bug in what I just uploaded. You need to comment out the 'g_list_foreach (profiles, (GFunc)g_object_unref, NULL);' line in backends/gstreamer/rb-player-gst.c:get_profile_from_mime_type
Created attachment 81740 [details] [review] better patch Fixes the above bug, and also makes it so that iPods can actually play transcoded tracks. They seem to choose the decoder solely on the file extension, so this means that we should really hold a map of things like audio/mpeg->mp3 and the like - but most people would have their audio encoding profiles set correctly. With this patch, copying any assortment of tracks to my ipod (with the ipod plugin, and generic plugin) works well for me. The only issue I've noticed is the always-transcode one mentioned above.
What about data from .is_audio_player? My SE W800 phony wants songs in the MP3/ directory, so a way to configure that would be great.
That's an additional piece of code, that I haven't looked at yet - but it should be fairly simple to write. A UI to modify those things is further off though. Or you could edit HAL's .fdi file to add the data and submit a patch to HAL so the device is supported for everyone :)
I've committed the patch to svn. We still need to do things like not always transcoding, and some UI for options, but the basics work.
This is with ubuntu's 0.9.7.90: Perhaps there's missing a dot in some g_strdup_printf calls in impl_build_dest_uri() ? I got a file called "0 - Rentmp3" on my phone from rhythmbox.
(In reply to comment #31) > This is with ubuntu's 0.9.7.90: > Perhaps there's missing a dot in some g_strdup_printf calls in > impl_build_dest_uri() ? > I got a file called "0 - Rentmp3" on my phone from rhythmbox. Fixed in svn, we were using the wrong variable for the extension.
One thing I've noticed is that rhythmbox only looks at the first mimetype in the list that the player supports. So if my player supports both mp3 and ogg files, the mp3s will transfer fine, but the oggs will fail silently, with this debug output: (14:15:37) [0x80f3078] [impl_paste] rb-removable-media-source.c:302: failed to find acceptable mime type for file:///home/adam/music/Arthur%20Yoria/Ill%20Be%20Here%20Awake/02-Permanent-Arthur%20Yoria.ogg If I have an encoding profile set up for mp3, oggs will be transcoded to mp3 instead of being simply transferred. This is with today's svn.
There are two things that cause this: 1) The new code that determines the preferred format doesn't check if it's already in an acceptable format. This means that it will always try to transcode, unless the "preferred" format happens to turn out to be the original format. Oops. 2) HAL's FDI file uses "application/ogg" when it probably means "audio/vorbis". When matching encoders we only look for audio encoding elements - which means the Ogg Vorbis pipeline never matches.
(In reply to comment #34) > 2) HAL's FDI file uses "application/ogg" when it probably means "audio/vorbis". > When matching encoders we only look for audio encoding elements - which means > the Ogg Vorbis pipeline never matches. Has this been brought to the attention of the HAL developers? I didn't notice anything that looked like this problem in the freedesktop bugzilla.
I asked them about it a while back, but I don't think we got anything sorted out, so I'll ask again. In any case, I've just committed a change to svn trunk to map application/ogg to audio/x-vorbis.
Created attachment 85133 [details] [review] use the format a track is already in if possible This might qualify under "dirty dirty hack", and I suspect the code could be better (this is my first real foray into C), but this patch seems to work for me. It goes through the mime_types list, and if it contains the mime type of the current track, it copies it to the front of the list. This ensures that if an encoder is set up for that type, it will be chosen first, and the track will not be reencoded. If there is no encoder for the type, or if the mime-type of the track is not on the list, it should have no effect. There is likely a much better way to solve the problem, but I figured I'd throw this out there, just in case. It's only been tested a few times, so there could easily be bugs.
Created attachment 85134 [details] [review] slightly cleaner patch Just realized I don't need to cast entry_mime to a char* now that I'm using g_strdup to copy the string before I put it into the list.
I've added a more correct version to svn. Thanks for the patch. Setting per-device options is now bug #422975, and the other enchancements mentioned here already have other bugs for them. Marking fixed.