GNOME Bugzilla – Bug 310774
RFE: I would like to be able to sync music to my iPod
Last modified: 2011-07-26 19:46:26 UTC
Distribution/Version: Debian Testing Just what the summary says. I've searched the menus and haven't found a sycn to ipod option. I've tried dragging files from my local library to the ipod icon, when it is plugged in. This doesn't work.
The CVS version of Rhythmbox already has iPod support.
It doesn't have sync support. Teppo, please be more careful when closing bugs.
Does current CVS have sync support now?
I just thought I'd add what kind of sync I want. To me, there are several modes 1) iPod ------> HD (Hard Disk) This mode copies from the iPod to the HardDisk, updating and deleting if necessary. 2) iPod ------>+ HD This mode copies from the iPod to the HardDisk, updating if necessary, but does NOT delete. 3) iPod <------- HD This mode copies from the HD to the iPod, updating and deleting if necessary. This is what iTunes does. 4) iPod +<------- HD This mode copies from HD to the iPod, updating, but does NOT delete 5) iPod +<------>+ HD This mode attempts to sync them both. It copies missing songs from the iPod to the HardDisk (missing = not present on HardDisk), and copies songs from the HardDisk to the iPod. It does not delete, either on iPod or on the Hard Disk. As for deciding - perhaps it can have preferences (only 2 are necessary - direction and delete yes/no), or an automatic decision. I can't think of an automatic decision that would work in a reasonable manner, maybe you can.
Created attachment 62634 [details] [review] Preliminary patch This patch against CVS HEAD adds some rough iPod syncing support. What you can do at the moment is copying files from your library to the iPod. It doesn't make any checks for duplicates, and probably has some other issues
Created attachment 62718 [details] [review] add missing include a s/RBLibrarySource/RBBrowserSource From what I understand, RBBrowserSource should be used instead of RBLibrarySource for source who wants a library-like view, please correct me if it's a wrong assumption.
Yes, RBBrowserSource (the best name we could come up with) provides the library-like view for a particular entry type, and RBLibrarySource is the actual "Library" source. A few comments on the patch: * you can just use rb_true_function instead of writing a impl_can_paste that just returns true. * there are a heap of extraneous spacing changes * impl_paste checks if the entry is a radio station or podcast. This got improved in the library source, by getting the "primary source" for the entry type (rb_shell_get_source_by_entry_type), and checking rb_source_can_paste for it. * I'm not sure how impl_receive_drag should handle URIs that aren't entries, which can happen if the user drags something from an external program.
Would it make more sense to rename RBBrowserSource to RBLibraryEntrySource? If RBBrowserSource does indeed provied a "library-like" view for a particular entry, then that "library-like" view is essentially how the library would see the entry? Just a thought. Also, what kind of support is there for "syncing" the playcounts and ratings from an iPod to the Rhythmbox DB? A colleague of mine has asked, and I didn't know the answer.
RBBrowserSource seems fine to me. What do you mean exactly by « syncing" the playcounts and ratings from an iPod to the Rhythmbox DB » ? When an iPod is plugged, you want the playcounts and ratings to be read from the iPod, and then for each iPod song, the new playcount and rating should be assigned to some (which one?) song in the library?
Yeah, that's exactly what I was thinking. I'm sure the tags could be used to match up the files (or maybe an MD5 Sum)? also, I think that if this were done, people would make good use of it (or turn it off if they didn't like it). I keep my iPod plugged into my PC so that I am able to charge it and add songs when I remember what I want to listen to on the plane/train/automobile. I can't (and don't want to) put my whole music library on my iPod, so if I play a song a lot from my local machine, I think the popularity of that song should be noted on my iPod. On the flip side, if I listen to a song alot on my iPod, Rhythmbox should be able to recognize that and adjust accordingly. If I knew any details about the internals of how this should be done, I'd be glad to help. Rhythmbox seems like a complex program to just dive into!
Created attachment 63724 [details] [review] Patch against CVS HEAD which disables iPod dnd if ENABLE_TRACK_TRANSFER is disabled
I'll test this tonight when I get home from work and let you know how it goes! Hopefully all goes well and iPod -> RB transfer can be next? ;)
(In reply to comment #12) > I'll test this tonight when I get home from work and let you know how it goes! > Hopefully all goes well and iPod -> RB transfer can be next? ;) > I'm having trouble compiling this. This is the error that I'm getting, along with the arguements that I pass to autogen.sh cc1: warnings being treated as errors ../../sources/rb-ipod-source.c: In function 'completed_cb': ../../sources/rb-ipod-source.c:829: warning: implicit declaration of function 'itdb_schedule_save' ../../sources/rb-ipod-source.c:829: warning: nested extern declaration of 'itdb_schedule_save' make[3]: *** [rb-ipod-source.lo] Error 1 make[3]: Leaving directory `/builds/rhythmbox/plugins/ipod' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/builds/rhythmbox/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/builds/rhythmbox' make: *** [all] Error 2 ./autogen.sh --prefix=/usr --with-ipod --enable-tag-writing --enable-audioscrobbler --enable-lirc --with-hal --with-dbus --with-plugins=all --enable-libnotify --enable-daap --enable-musicbrainz --enable-track-transfer I'm running Fedora Core 5 with a custom-built 2.6.16.5 kernel. Let me know if there is anything that I can do to help.
The problem is that the patch uses stuff from the cvs version of libgpod, an Christophe forgot to bump the version requirements in configure.ac.
Created attachment 63775 [details] [review] New patch which compiles The previous patch was dependent on another patch in my bzr tree where I introduced itdb_schedule_save, it's not a new API in libgpod. This patch is compile-tested this time, so it should work. As for ipod=>library copying, I think this should work with CVS if you pass --enable-track-transfer to configure (library=>ipod copying doesn't work without enabling that anyway)
Created attachment 63788 [details] [review] Same patch without the white space changes (I blame my emacs conf ;)
I committed this patch to CVS, but I'm keeping this bug open since it doesn't achieve "ipod synchronization", it's just a "let me add a song as many times as I want to the iPod" feature, which is far better than nothing, but that could be even better ;)
Created attachment 64528 [details] [review] playlist, transcoding and synchronization this is a snapshot of what i've here in my tree. It's still pretty rough, and obviously not meant to be committed ;) With these changes you can add and remove playlists, podcasts and songs. If you create a GNOME mp3 audio profile (example pipeline: "lame bitrate=128"), you can add files in non-mp3 format and they will automatically be transcoded. You have to explicitly press the Synchronize button to start writing changes to the ipod. If you press it again, the synchronization will be paused and you can restart it later. At any point in time you can eject the iPod or quit RB. If the synchronization is running, it will automatically get cancelled. There are some known issues: in RBiPodManager IPOD_MAX_PATH_LEN is set to 56 chars. If a pathname exceeds these 56 chars it's truncated, so if you try to add two or more files with the same common prefix which exceeds this length, only the first file will be added. The transcoding progress bar is broken, that's due to the way progress is calculated in RBEncoderGst. If you add an entry and then try to readd it, it won't get added again. But if you add an entry, close RB and reopen it, and try to readd the same entry it will get added. This is because iPod URI <-> Library URI correspondences are kept in memory and not written anywhere. gtkpod uses an extended itunes db file or something, we could maybe just use a (specialized) RhythmDB? ... ... to be continued ... :) I've only tested this stuff with an iPod nano, please test it with other models
(In reply to comment #18) > this is a snapshot of what i've here in my tree. It's still pretty rough, and > obviously not meant to be committed ;) The patch looks fairly sane to me. Apart from Christophe, I don't think any of the developers have an iPod, so us doing testing could be hard. I'd be happy to commit a patch to cvs, and mail the ML, so we can get some more widespread testing. If you want to do that let me know; it doesn't have to be finished, as long as it doesn't have known "your ipod will catch on fire" bugs, it should be fine. Regarding paralell transfers, I'd thought about that earlier but hadn't implemented anything. Probably the best thing I've thought of is allowing one transfer of each entry-type concurrently. This would allow you to rip a cd, copy at track from a daap share, and sync to your ipod at the same time. Generally copying two tracks to the same source shouldn't be too much of a problem, it just might go a bit slower, whereas trying to copy two from a source would be bad (e.g. ripping two tracks from the same cd). > With these changes you can add and remove playlists, podcasts and songs. If you > create a GNOME mp3 audio profile (example pipeline: "lame bitrate=128"), you > can add files in non-mp3 format and they will automatically be transcoded. Ideally we'd read the supported mime-types from HAL (if using a hal-enabled build) so we automagically use whatever formats the device does. However I need to fix RBEncoder so that it takes a list of mime-types, doesn't transcode if it matches any of those, and can transcode to any of those types (the first one that the user has an encoding profile for). > You have to explicitly press the Synchronize button to start writing changes to > the ipod. If you press it again, the synchronization will be paused and you can > restart it later. > At any point in time you can eject the iPod or quit RB. If the synchronization > is running, it will automatically get cancelled. Sounds good to me; popping up a "you have unsynchronised changes, you would like to sync before quitting?" message would be nice. That would require adding a signal plugins can hook into to take action/block a quit, which I wanted to add for something else anyway. > If you add an entry and then try to readd it, it won't get added again. But if > you add an entry, close RB and reopen it, and try to readd the same entry it > will get added. This is because iPod URI <-> Library URI correspondences are > kept in memory and not written anywhere. gtkpod uses an extended itunes db file > or something, we could maybe just use a (specialized) RhythmDB? What is needed for storing this is similar to the idea I had for caching metadata on generic player devices. We either need to add support to rhythmdb for storing arbitrary metadata, or store it outside the db. My current idea is storing files under ~/.gnome2/rhythmbox/devices/ with the data. If iPods have unique IDs (aside from the HAL one), we could use a file called "ipod-$IPODID" in that folder or "hal-$HALID" for generic players. For iPods it would store the ipod uri <-> library uri mapping. For generic players it could basically be a rhythmdb xml file with the metadata. If that sounds okay to you, it shouldn't be too hard to whip up something that does saves he mapping to ~/.gnome2/rhythmbox/devices/ipod-$IPODID.xml. When an ipod is detected, we can just look for that file to know whether we've seen it before, and load the mapping if it exists.
Sorry for the late reply, i've been having problems with my home connection (In reply to comment #19) > The patch looks fairly sane to me. Apart from Christophe, I don't think any of > the developers have an iPod, so us doing testing could be hard. > > I'd be happy to commit a patch to cvs, and mail the ML, so we can get some more > widespread testing. If you want to do that let me know; it doesn't have to be > finished, as long as it doesn't have known "your ipod will catch on fire" bugs, > it should be fine. To me it's absolutely ok to commit it > Ideally we'd read the supported mime-types from HAL (if using a hal-enabled > build) so we automagically use whatever formats the device does. However I need > to fix RBEncoder so that it takes a list of mime-types, doesn't transcode if it > matches any of those, and can transcode to any of those types (the first one > that the user has an encoding profile for). It's not easy to abstract a media stream. For example i think RBEncoder should at least be aware of the difference between a container format and an audio codec format, to distinguish for example an id3 muxed flac from an id3 muxed mp3 file. Are you sure you want to keep the abstraction from GMAudioProfile? Working with profile names would just be a lot simpler. Plus, GMAudioProfile is already thightly coupled to RB in RBSourceLibrary. > What is needed for storing this is similar to the idea I had for caching > metadata on generic player devices. We either need to add support to rhythmdb > for storing arbitrary metadata, or store it outside the db. > > My current idea is storing files under ~/.gnome2/rhythmbox/devices/ with the > data. If iPods have unique IDs (aside from the HAL one), we could use a file > called "ipod-$IPODID" in that folder or "hal-$HALID" for generic players. This would be perfect. I'm not sure iPods have uids, but maybe we could generate one in /mountpoint/iPod_Control/ ?
> This would be perfect. > I'm not sure iPods have uids, but maybe we could generate one in > /mountpoint/iPod_Control/ ? > They do have a serial number which should be available from iPod_Control/Device/SysInfo (don't remember the exact file). libipoddevice is probably able to get it.
(In reply to comment #18) > > With these changes you can add and remove playlists, podcasts and songs. Does "playlists" include smart playlists as well? > > You have to explicitly press the Synchronize button to start writing changes to > the ipod. How is it better than adding the new tracks to the iPod right away? > > There are some known issues: > in RBiPodManager IPOD_MAX_PATH_LEN is set to 56 chars. If a pathname exceeds > these 56 chars it's truncated, so if you try to add two or more files with the > same common prefix which exceeds this length, only the first file will be > added. Those files with the same name should end up in different directories (eg f05 and f17), the current code in CVS HEAD tries several times to find an appropriate directory if there are such name conflicts. I'll try to look at the patch soon, I only noticed it today
Created attachment 65097 [details] [review] Patch rediffed against CVS without the new files (sorry for not putting the new files in, I'm being lazy ;) There's a new AM_PATH_CHECK in configure.ac, I don't seem to have the appropriate macro installed, is that something needed by the patch?
(In reply to comment #23) > Created an attachment (id=65097) [edit] > Patch rediffed against CVS without the new files > > (sorry for not putting the new files in, I'm being lazy ;) There's a new > AM_PATH_CHECK in configure.ac, I don't seem to have the appropriate macro > installed, is that something needed by the patch? Yeah sorry that's needed to build the (incomplete) testsuite. You can either install check (check.sf.net) or remove it altogether.
(In reply to comment #22) > > With these changes you can add and remove playlists, podcasts and songs. > Does "playlists" include smart playlists as well? Nope. > > You have to explicitly press the Synchronize button to start writing changes to > > the ipod. > How is it better than adding the new tracks to the iPod right away? Transcoding can be slow and *very* resource-intensive. On a not-so-new pc i get jitter if I start transcoding while i'm playing something. Anyway i don't have a strong opinion here. > Those files with the same name should end up in different directories (eg f05 > and f17), the current code in CVS HEAD tries several times to find an > appropriate directory if there are such name conflicts. Right, but you can still get conflicts. > I'll try to look at the patch soon, I only noticed it today Great!
Btw Alessandro, are you using an arch tree or something for that code? If so, is it publicly available?
(In reply to comment #26) > Btw Alessandro, are you using an arch tree or something for that code? If so, > is it publicly available? Yep i'm using bzr. It was publicly available before my ADSL got screwed up... Now it's not, as i don't have any public server to put it on.
(In reply to comment #20) > > Ideally we'd read the supported mime-types from HAL (if using a hal-enabled > > build) so we automagically use whatever formats the device does. However I need > > to fix RBEncoder so that it takes a list of mime-types, doesn't transcode if it > > matches any of those, and can transcode to any of those types (the first one > > that the user has an encoding profile for). > > It's not easy to abstract a media stream. For example i think RBEncoder should > at least be aware of the difference between a container format and an audio > codec format, to distinguish for example an id3 muxed flac from an id3 muxed > mp3 file. I was more thinking that the types you would pass would be "audio/mpeg" and "audio/x-vorbis", and RBEncoder would choose the container/tagging format (for the gst backend, by using whatever is in the profile pipeline). Trying to specify it furthur, with container formats, tagging formats, and stream specifics (such as what kind of audio/mpeg is supported) is very complicated and no-one has a real solution to it. In any case, HAL doesn't give us any more info than the supported audio stream types anyway (although it reports application/ogg instead of audio/x-vorbis, which is dumb). If we had to choose container/tagging formats ourselves, rather than using the profile pipeline, choosing the canonical formats should work well enough. The likelyhood that a device supports Vorbis but not in an ogg container, or MP3s with APE tags but not ID3 ones, is fairly small. > Are you sure you want to keep the abstraction from GMAudioProfile? > Working with profile names would just be a lot simpler. Most things that will be using RBEncoder (with the exception of ripping CDs) will know what mime-type(s) they wants, so will have to do a mimetype->profile lookup anyway. > Plus, GMAudioProfile is > already thightly coupled to RB in RBSourceLibrary. The two bits in RBLibrarySource that use GMAudioProfile are the encoder-specific preference(s), and picking the extension for the file name. They could both be fixed by making the source pass those off to the RBEncoder implementation, but I hadn't been inspired enought to do that, > > My current idea is storing files under ~/.gnome2/rhythmbox/devices/ with the > > data. If iPods have unique IDs (aside from the HAL one), we could use a file > > called "ipod-$IPODID" in that folder or "hal-$HALID" for generic players. > > This would be perfect. > I'm not sure iPods have uids, but maybe we could generate one in > /mountpoint/iPod_Control/ ? If we can use the ipod serial number (as Christophe mentioned) that would be better, as it would work on non-HAL systems.
Created attachment 65418 [details] [review] fix assorted warnings etc This update fixes a few compile warnings and spacing issues (like tabs at the end of lines). Christophe: Do you think this is good enought to commit, or does it need work? Feel free to commit it if you think it's okay.
Still a couple of issues, your patch is missing rb-ipod-playlist-source.c (or whatever the name), the musicdirs Itdb_iTunesDB member is gone in newer libgpod releases (not a big issue, I can fix it once it's in CVS), cf http://gtkpod.cvs.sourceforge.net/gtkpod/libgpod/src/itdb.h?r1=1.28&r2=1.29 There are still some compile warnings, I'll attach a patch for those I hit before the compile failed because rb-ipod-playlist-source.c is missing. Dunno if these are the correct fix, but they make sense to me. And before that goes in, I'd like to have a look at that patch first (though if I don't do it before next week-end, I guess it can just be committed ;)
Created attachment 65455 [details] [review] Warning fixes Goes on top of previous patch
Ah, and I'm a bit concerned about the added 'check' dependency, dunno if we want it or not. (if it's still in your latest patch)
What gcc version are you guys using? I'm sorry I can't help, I always compile with -Wall -Werror but with gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) i don't get any warning.
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) but I think I'm keeping the default flags used by rhythmbox (-Wall -Werror and a bunch of additional flags iirc)
Created attachment 65581 [details] Missing file from the previous patch, attaching it not to lose it ;)
Created attachment 65587 [details] [review] Updated patch This is a cumulative patch of the last 3 attachements. It compiles on my machine (apart from my issue with using a too new libgpod).
Passing "--enable-more-warnings" to configure will automatically turn on -Wall -Werror and a number of others. w.r.t check, it doesn't seem to give us a whole lot that we couldn't do with some printf()s. I'd still be happy to have it as an optional dependency, except that it *requires* everyone building from cvs to have it installed (autoconf will fail without it installed).
If we really want it, check.m4 can probably added to macros/, this should be enough to make it optional for CVS users as well.
Doesn't seem to compile without --enable-track-transfer: rb-ipod-manager.c: In function 'rb_ipod_manager_init': rb-ipod-manager.c:362: error: 'struct _RBiPodManagerPrivate' has no member named 'mime_type' rb-ipod-manager.c: In function 'rb_ipod_manager_finalize': rb-ipod-manager.c:386: error: 'struct _RBiPodManagerPrivate' has no member named 'mime_type'
Compiling with the patch from #36 and --enable-track-transfer compiles OK, but won't load the iPod plugin because of: Rhythmbox-WARNING **: /usr/lib/rhythmbox/plugins/libipod.so: undefined symbol: rb_ipod_entry_set_from_track Rhythmbox-WARNING **: Could not load plugin file at /usr/lib/rhythmbox/plugins/libipod.so Rhythmbox-WARNING **: Error, impossible to activate plugin 'iPod support'
Paul, did you rerun autogen.sh after applying the patch? I'm not getting that here, though dnd'ing files to the iPod doesn't work :-/
Christophe, * I checked out from todays anoncvs. * applied the patch * ran ./autogen.sh * ran 'make dist' then copied the resultant tarball over to one of my buildboxes, added a debian/ directory and built a .deb out of it. Basically the same as I usually do for testing things from CVS, is there something else specific to this patch that i'm missing perhaps?
The way you do it add steps that could break. It would be great if you could try to install it directly from the CVS tree (make dist might be broken for example)
A tarball generated with make dist doesn't compile here because it's missing rb-ipod.h
(In reply to comment #41) > Paul, did you rerun autogen.sh after applying the patch? I'm not getting that > here, though dnd'ing files to the iPod doesn't work :-/ What kind of files? mp3? non-mp3? To sync non-mp3 files you'd have to create a GNOME profile that can output mp3 (eg: "lame bitrate=128") Also, could you run it with -Dipod and attach the output here please?
(In reply to comment #45) > (In reply to comment #41) > What kind of files? mp3? non-mp3? To sync non-mp3 files you'd have to create a > GNOME profile that can output mp3 (eg: "lame bitrate=128") This was with mp3 files, CVS HEAD without the patch was able to add them properly to the iPod > Also, could you run it with -Dipod and attach the output here please? I'll give it a try, dunno when I'll have time...
Created attachment 65932 [details] [review] fixes 'make dist' The current patch doesn't correctly dist some of the .h files -- this patch can be applied on top of the existing one to fix that. With this, a 'make dist''ed tarball can be made which compiles and transfers tracks.
Created attachment 65952 [details] [review] updated patch Fixes make dist and compiles with --enable-more-warnings. Also works a lot better if ENABLE_TRACK_TRANSFER is not defined, allowing you to still remove tracks and manage playlists.
Created attachment 65967 [details] [review] updated patch (testsuite included) forgot to add the testsuite in the previous diff.
Created attachment 65974 [details] [review] Updates Alessandro's patch to current CVS Changes the patch to compile against current CVS (the rhythmdb splitup)
Alessandro, Is there a reason why you recommend disabling the track transfer code to make this patch work? I've been using it over the weekend with --enable-track-transfer (and tag writing) and it seems to copy MP3 files to and from my available iPod's (a shuffle, a mini and a video) with no major complaints?
(In reply to comment #51) > Is there a reason why you recommend disabling the track transfer code to make > this patch work? I don't recommend it. I just want the plugin to compile whether the track transfer code is enabled or not. > I've been using it over the weekend with > --enable-track-transfer (and tag writing) and it seems to copy MP3 files to and > from my available iPod's (a shuffle, a mini and a video) with no major > complaints? Great! Thanks for your work!
Alessandro, wrt the patch not transferring tracks when I tested it, I just remembered that to get it to compile I commented out one line (a function which has been removed from libgpod head), so I don't think I should expect it to work after that :p I'll get it to work with libgpod HEAD when I find time...
(In reply to comment #52) > (In reply to comment #51) > > Is there a reason why you recommend disabling the track transfer code to make > > this patch work? > I don't recommend it. I just want the plugin to compile whether the track > transfer code is enabled or not. OK, that's understandable. I'll a recompile without the track transfer code tomorrow and let you know how it works.
Created attachment 66237 [details] [review] use new type-specific entry data mechanism Updated to use RhythmDB's new type-specific entry data mechanism for the "status" field. Not having an ipod I haven't checked that this atually works, but it's a fairly trivial change.
(In reply to comment #45) > > What kind of files? mp3? non-mp3? To sync non-mp3 files you'd have to create a > GNOME profile that can output mp3 (eg: "lame bitrate=128") Not working with ogg either (and I have an mp3 profile since I can rip to mp3 with s-j > Also, could you run it with -Dipod and attach the output here please? > What do you mean exactly? Run rhythmbox -Dipod? Recompile rb with -Dipod in my CFLAGS? I couldn't find any corresponding #îfdef in the code.
Created attachment 66463 [details] Full log
Created attachment 66464 [details] Real full log I screwed up the first time, here is a full one this time
(In reply to comment #58) > Created an attachment (id=66464) [edit] > Real full log > > I screwed up the first time, here is a full one this time ... (11:08:04) [0x61e730] [rb_ipod_source_playlist_add_track] ../../sources/rb-ipod-source.c:521: adding file:///media/ipod/iPod_Control/Music/f43/le_petit_castor.mp3 to playlist poPod (11:08:04) [0x61e730] [playlist_track_added] rb-ipod-manager.c:1160: added track file:///home/anevia/mp3/yelomolo/melimelo/le_petit_castor.ogg to playlist poPod(11:08:04) [0x61e730] [rb_ipod_source_playlist_add_track] ../../sources/rb-ipod-source.c:521: adding file:///media/ipod/iPod_Control/Music/f49/le_sentier_troit.mp3 to playlist poPod (11:08:04) [0x61e730] [playlist_track_added] rb-ipod-manager.c:1160: added track file:///home/anevia/mp3/yelomolo/melimelo/le_sentier_troit.ogg to playlist poPod ... From the log it seems the tracks are being added correctly. You have to toggle the Synchronize button to copy the tracks and write the changes to the itdb.
Ah, right, I had forgotten it doesn't "just work", but that you need to press a sync button ;) Ok, still doesn't work, get_profile_from_mime_type lacks a "error = NULL" in the if (error) { g_error_free (error); continue; } block, otherwise libc complains about double-free. With that addition, rb properly reports failure when trying to transfer the tracks (they are ogg files, so I guess my system isn't properly set up for transcoding, but I don't have enough time to investigate)
Created attachment 67073 [details] [review] updated patch Updated to work on HEAD. I've also set the sorting-key for the ipod source and implemented RBSource::impl_get_browser_key and RBBrowserSource::impl_get_paned_key.
(In reply to comment #61) The sorting key needs to be changed. I used the same key as the library, but that would break sorting of the library if the key is set to the Status column on the ipod.
Is it possible to set up the ability to copy music from a daap share to the ipod?
William, I reckon your question means that you tried but this is not working, while copying from the main library to the iPod works? Or is it just out of curiosity? I have always wondered if there was something special to do to get daap=>ipod transfers to work, but I'm not using daap so I never tested it.
In theory it should just work, as the ipod doesn't care where it's copying from, and daap->library works.
And it should work with my patch too, as RBEncoderGst uses the GstURIHandler interface which daapsrc seems to provide. Not having tested, i'm not 100% sure though.
I have tested. It copies from daap to library. It looks like it is copying from daap to ipod, but it doesn't. Somewhat related to bug #345248. In that bug it looks like it is copying, but it doesn't. To test, I would suggest that you install the tangerine server (gnomefiles) and copy some music to that dir.
Created attachment 68593 [details] [review] updated patch Updated do apply on HEAD
Created attachment 69645 [details] [review] updated patch Updates the patch to current CVS, as of 26/07/2006 +1000. Compiles OK, seems to work OK (has been playing off two iPods for an hour) -- but another few pairs of eyes might not hurt.
It's not compiling for me because get_db_for_source is defined but not used. #if 0ing it fixes the problem.
The first chunk in that patch has nothing iPod specific in it, it's a rb-encoder bug fix, so at least that part could go in ;) diff -urpN rhythmbox-0.9.5.orig/backends/gstreamer/rb-encoder-gst.c rhythmbox-0.9.5/backends/gstreamer/rb-encoder-gst.c --- rhythmbox-0.9.5.orig/backends/gstreamer/rb-encoder-gst.c 2006-07-19 17:22:36.000000000 +1000 +++ rhythmbox-0.9.5/backends/gstreamer/rb-encoder-gst.c 2006-07-26 17:04:09.000000000 +1000 @@ -685,6 +685,7 @@ get_profile_from_mime_type (const char * g_free (pipeline_description); if (error) { g_error_free (error); + error = NULL; continue; } I can't help having the feeling that the rest of the code is overly complicated for what it's doing, but I didn't take time to sit and review the code :-/ And I still don't like this explicit "synchronize" button ;) But that's another issue :) Thanks for updating the patch!
Christophe, The first part has been there since the beginning, so you're probably right that it should probably be pushed upstream if it indeed fixes an actual bug. As for the "synchronize" button, i've got more of an issue with the "eject" button myself, and the fact that it should really be a "right-click on the device" function, rather than "click from the program" one. Although, IIRC -- Banshee also does a similar thing i.r.t button layout.
(In reply to comment #72) > The first part has been there since the beginning, so you're probably right > that it should probably be pushed upstream if it indeed fixes an actual bug. I think I added it since I was getting crashes without it ;) So yeah, it fixes a bug > > As for the "synchronize" button, i've got more of an issue with the "eject" > button myself, and the fact that it should really be a "right-click on the > device" function, rather than "click from the program" one. On my ubuntu breezy, I can do both (eject from rb as well as eject from "the desktop" ie nautilus) > > Although, IIRC -- Banshee also does a similar thing i.r.t button layout. What do you mean? That it has "Synchronize" or "Eject"?
(In reply to comment #73) > > As for the "synchronize" button, i've got more of an issue with the "eject" > > button myself, and the fact that it should really be a "right-click on the > > device" function, rather than "click from the program" one. > > On my ubuntu breezy, I can do both (eject from rb as well as eject from "the > desktop" ie nautilus) ... and "ejecting" the device is probably something that is best left to the desktop, rather than the individual applications :) > > > > Although, IIRC -- Banshee also does a similar thing i.r.t button layout. > > What do you mean? That it has "Synchronize" or "Eject"? That it has a synchronize button after you've actually done something with the device -- which kind of reminds you that you should actually press it before closing the app.
(In reply to comment #71) [snip] > I can't help having the feeling that the rest of the code is overly complicated > for what it's doing, but I didn't take time to sit and review the code :-/ The rest of the code (RBiPodManager) does what is needed to keep the iTunesDB always synchronized with what is *actually* on the iPod rather than what is scheduled to be on it. If you remove RBiPodManager and RB crashes in the middle of a synchronization, your iTunesDB will be in an inconsistent state. The iPod will show you tracks that it'll never be able to play. Also consider my use case: I don't have any mp3s, my music collection is in ogg/vorbis and flac. When I add something to the iPod, that needs to be transcoded. Transcoding takes time. Copying a couple of CDs on the ipod can take hours. For me it is fundamental to be able to just stop the synchronization, eject the iPod and have it in a working shape. I think RBiPodManager could be generalized, as the synchronization problem applies to other removable devices too. > And I still don't like this explicit "synchronize" button ;) But that's another > issue :) I already replied on this. Anyway if it's really that annoying for you, maybe we could use an "auto synchronize" property or something.
To get things straight, I'm not saying your code is useless, on the contrary, it seems like a good framework to have. I'm just vaguely worried about some parts of the implementation, but without having looked at it, I'm just FUDing, maybe it's as good as it can be done :) Fwiw, the current code writes the iTunesDB *after* each successful copy, so it shouldn't show you tracks it can't play. And I agree that cancellable transcoding is something really useful, I didn't mean it's useless, don't worry :) Sorry if my comments made me sound as if a straight rejection of the patch as a whole, this is far from being the case. I want your code, but I'd feel more comfortable if I was sure it's easy enough to maintain :)
(In reply to comment #76) > To get things straight No need to really. I understand and appreciate your criticism. I'm not completely happy with the code myself. > it seems like a good framework to have. I'm just vaguely worried about some > parts of the implementation, but without having looked at it, I'm just FUDing, > maybe it's as good as it can be done :) No it's not :). Most of RBiPodManager is highly tied to libgpod's API, which is wrong and ugly. As I said, it should be generalized and I actually started working on that but haven't had much time lately. I plan on hacking on it soon, but first i'll ask for input on the mailing list.
I've committed the RBEncoderGst fix to cvs.
Does the track transfer code do transcoding right now? My FLAC songs get copied as-is, and I have the following audio profile defined: audio/x-raw-float,rate=44100,channels=2 ! lame name=enc,profile=1001 ! xingmux ! id3mux I selected this profile as the default RB encoder profile, but the song just gets copied as is.
I would like to know this also. I cannot get rb to transcode flac or ogg to mp3 on transfer.
I also would like to know whether this functionality is in fact functional. I have a profile setup to encode to mp3 yet the file gets copied directly. Error handling should be a bit better here. The track shouldn't be copied at all if it can't for transcoded for whatever reason. Oggs crash my iPod nano, extremely aggrevating.
*** Bug 396292 has been marked as a duplicate of this bug. ***
What's current status on this? Presumably a lot of the most recent patch duplicates stuff in current SVN rb-ipod-source.c?
I've been using rhythmbox (SVN HEAD) with my ipod pretty reliably recently. The transcoding functionality works fairly well, although I had to setup an encoding profile with the following pipeline: audio/x-raw-int,rate=44100,channels=2 ! lame name=enc. My one remaining complaint is that the UI becomes extremely sluggish during data transfer. It is perfectly responsive during the transcode process but comes to a halt for pretty prolonged periods of time while copying (at least this is what I presume it is doing). If the copy and transcode processes are in fact separate processes, refactoring them into two threads/queues could speed the process. It should be entirely possible to be copying mp3/already transcoded files to the device while another file is being transcoded.
Nah, the transcoder writes directly to the iPod, and does so in a GStreamer thread. It's probably the writing out of the iTunes database; itdb_schedule_save has a FIXME about that. It should be doable to move the itdb_write call into a thread, but we'll have to add a load of locking stuff.
(In reply to comment #83) > What's current status on this? Presumably a lot of the most recent patch > duplicates stuff in current SVN rb-ipod-source.c? Some of it yes. The patch also let you edit playlists on iPods, which SVN doesn't currently do. Much of that extra functionality should be common to all media players, with small specific bits like actually writing the playlists our. If someone was interesting up updating/re-writing this, that would be great. This is closer to the top of my media player todo list, but as always I can't guarantee that I'll actually get around to it any time soon.
Also requested on https://bugs.launchpad.net/rhythmbox/+bug/109192
I agree with this. Syncing is a must have. I'm fed up of trying to sort out which songs I need to copy to and from my iPod. It shouldn't be iPod specific, but be for all players.
Alex Lancaster, I disagree with changing the component from removable media to ipod, because it should not be ipod specific, but for all portable players.
(In reply to comment #89) > Alex Lancaster, I disagree with changing the component from removable media to > ipod, because it should not be ipod specific, but for all portable players. This particular bug (and all the patches that have been attached) is currently iPod-specific. While I agree that ultimately we should be able to sync music to any portable players, there's no sense in increasing the scope of this particular bug unless one of the devs decides that it's necessary. You could open a new bug for any generic synching, and then this bug could be made to depend on that one (assuming that it would use some of the underlying code). There may even be a such a bug (didn't find one in my short search on bugzilla).
Here's a ipod sync plugin made by KittyPee. Maybe that can helps : http://www.kittypee.com/2007/11/16/rhythmbox-ipod-sync-plugin/
(In reply to comment #91) > Here's a ipod sync plugin made by KittyPee. Maybe that can helps : No, that seems to be a workaround for bug 374076.
Syncing needs to be included. It is something that is really bothering me with Rhythmbox. Its a huge inconvenience
What's the current status on this? Is real sync implemented yet?
I'd complete rhythmbox. What some users need is, to sync ratings and play count number, i've found a guy who made a rather primitive pluging to do this. http://www.kittypee.com/2007/11/16/rhythmbox-ipod-sync-plugin/ And the updated it. http://www.kittypee.com/2008/04/22/updated-rhythmbox-ipod-sync-plugin/
I'm really waiting for this feature too. Will it be included in the next release?
dont think so, the developers have their heads in a hole in the ground and dont think this "ipod" thingy its important or might have significance in an mp3 player, the mere idea is ridiculous to them
(In reply to comment #98) > dont think so, the developers have their heads in a hole in the ground and dont > think this "ipod" thingy its important or might have significance in an mp3 > player, the mere idea is ridiculous to them > In defense to the developers, most of them (that I know of) don't have iPods. So unless you can A) to donate an iPod to the development effort, or B) assist in coding and testing patches, I think your comments are uncalled for. A bugzilla query that you may find interesting: http://bugzilla.gnome.org/buglist.cgi?product=rhythmbox&component=iPod&remaction=&query_format=advanced&query_based_on=&order=bugs.bug_status,bugs.bug_status%2Cbugs.bug_id&query_based_on= 57 iPod-related bugs, of which 28 are still outstanding. http://bugzilla.gnome.org/buglist.cgi?product=rhythmbox&bug_status=NEW&bug_status=REOPENED&bug_status=ASSIGNED&bug_status=UNCONFIRMED&component=iPod For a group of developers that (mostly) don't have the hardware, 50% is pretty good. Also, you mentioned in a previous comment 96 that users should be able to sync ratings and play counts. I agree. See bug 466670 for half of that equation. Feel free to open a bug for the other half, if you feel it necessary. I see no reason why this bug can't be closed. It's old, lengthy, hasn't been touched recently, and based on the summary, can be closed as FIXED not OBSOLETE. Any further improvements beyond the initial "sync music to my iPod" is worthy of a new bug. John
Guillermo, full ipod syncing isn't something trivial and it's quite some work, this is why this isn't done. If this feature is particularly important for you, feel free to help. Fwiw, the various bits required for that are slowly getting there.
*** Bug 595484 has been marked as a duplicate of this bug. ***
*** Bug 607387 has been marked as a duplicate of this bug. ***
I'll pitch in to buy an ipod if it would help development. here's my functional "spec" for ipod sync support: It would be much more convenient and awesome to set up a "sync profile" where I could choose which files from my music library are to be copied to the device. Then, when I plug it in and trigger a sync operation, the ipod would be made to look just like that "sync profile". Similar to itunes, but I should be able to create multiple sync profiles for different devices (ipod, android, etc).
I've just merged code based on Paul Bellamy's GSoC 2009 project into master. iPod sync now works.