After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 310774 - RFE: I would like to be able to sync music to my iPod
RFE: I would like to be able to sync music to my iPod
Status: RESOLVED FIXED
Product: rhythmbox
Classification: Other
Component: iPod
0.8.8
Other Linux
: Normal enhancement
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 396292 595484 607387 (view as bug list)
Depends on: 345725 411634
Blocks: 338564
 
 
Reported: 2005-07-18 15:50 UTC by Uri David Akavia
Modified: 2011-07-26 19:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Preliminary patch (21.63 KB, patch)
2006-04-02 20:48 UTC, Christophe Fergeau
none Details | Review
add missing include a s/RBLibrarySource/RBBrowserSource (29.33 KB, patch)
2006-04-04 08:30 UTC, Christophe Fergeau
none Details | Review
Patch against CVS HEAD which disables iPod dnd if ENABLE_TRACK_TRANSFER is disabled (11.36 KB, patch)
2006-04-17 16:45 UTC, Christophe Fergeau
none Details | Review
New patch which compiles (26.52 KB, patch)
2006-04-18 07:55 UTC, Christophe Fergeau
none Details | Review
Same patch without the white space changes (I blame my emacs conf ;) (12.34 KB, patch)
2006-04-18 11:36 UTC, Christophe Fergeau
committed Details | Review
playlist, transcoding and synchronization (159.93 KB, patch)
2006-04-29 16:50 UTC, Alessandro Decina
none Details | Review
Patch rediffed against CVS without the new files (66.04 KB, patch)
2006-05-09 16:25 UTC, Christophe Fergeau
none Details | Review
fix assorted warnings etc (150.19 KB, patch)
2006-05-14 06:56 UTC, James "Doc" Livingston
needs-work Details | Review
Warning fixes (2.55 KB, patch)
2006-05-14 20:05 UTC, Christophe Fergeau
none Details | Review
Missing file from the previous patch, attaching it not to lose it ;) (12.17 KB, text/plain)
2006-05-16 09:30 UTC, Christophe Fergeau
  Details
Updated patch (170.61 KB, patch)
2006-05-16 11:38 UTC, Christophe Fergeau
none Details | Review
fixes 'make dist' (708 bytes, patch)
2006-05-21 08:49 UTC, Paul Drain
none Details | Review
updated patch (147.28 KB, patch)
2006-05-21 16:56 UTC, Alessandro Decina
none Details | Review
updated patch (testsuite included) (158.53 KB, patch)
2006-05-21 20:56 UTC, Alessandro Decina
none Details | Review
Updates Alessandro's patch to current CVS (3.69 KB, patch)
2006-05-22 02:46 UTC, Paul Drain
none Details | Review
use new type-specific entry data mechanism (157.16 KB, patch)
2006-05-26 03:10 UTC, James "Doc" Livingston
none Details | Review
Full log (280.00 KB, text/plain)
2006-05-30 09:05 UTC, Christophe Fergeau
  Details
Real full log (308.69 KB, application/x-gzip)
2006-05-30 09:12 UTC, Christophe Fergeau
  Details
updated patch (155.59 KB, patch)
2006-06-09 22:19 UTC, Alessandro Decina
none Details | Review
updated patch (155.71 KB, patch)
2006-07-07 20:38 UTC, Alessandro Decina
none Details | Review
updated patch (178.77 KB, patch)
2006-07-26 08:40 UTC, Paul Drain
needs-work Details | Review

Description Uri David Akavia 2005-07-18 15:50:04 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.
Comment 1 Teppo Turtiainen 2005-07-18 18:20:33 UTC
The CVS version of Rhythmbox already has iPod support.
Comment 2 Bastien Nocera 2005-07-18 20:43:02 UTC
It doesn't have sync support.
Teppo, please be more careful when closing bugs.
Comment 3 Uri David Akavia 2005-11-26 16:41:40 UTC
Does current CVS have sync support now?
Comment 4 Uri David Akavia 2006-02-14 18:56:07 UTC
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.
Comment 5 Christophe Fergeau 2006-04-02 20:48:50 UTC
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
Comment 6 Christophe Fergeau 2006-04-04 08:30:40 UTC
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.
Comment 7 James "Doc" Livingston 2006-04-07 11:28:13 UTC
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.
Comment 8 John Daiker 2006-04-07 16:35:09 UTC
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.
Comment 9 Christophe Fergeau 2006-04-07 23:55:23 UTC
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?
Comment 10 John Daiker 2006-04-10 15:49:34 UTC
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!
Comment 11 Christophe Fergeau 2006-04-17 16:45:34 UTC
Created attachment 63724 [details] [review]
Patch against CVS HEAD which disables iPod dnd if ENABLE_TRACK_TRANSFER is disabled
Comment 12 John Daiker 2006-04-18 00:11:47 UTC
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? ;)
Comment 13 John Daiker 2006-04-18 03:30:54 UTC
(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.
Comment 14 James "Doc" Livingston 2006-04-18 06:13:55 UTC
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.
Comment 15 Christophe Fergeau 2006-04-18 07:55:00 UTC
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)
Comment 16 Christophe Fergeau 2006-04-18 11:36:20 UTC
Created attachment 63788 [details] [review]
Same patch without the white space changes (I blame my emacs conf ;)
Comment 17 Christophe Fergeau 2006-04-18 17:33:55 UTC
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 ;)
Comment 18 Alessandro Decina 2006-04-29 16:50:02 UTC
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
Comment 19 James "Doc" Livingston 2006-05-03 01:49:16 UTC
(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.
Comment 20 Alessandro Decina 2006-05-09 15:48:39 UTC
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/ ?
Comment 21 Christophe Fergeau 2006-05-09 15:57:19 UTC
> 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.

Comment 22 Christophe Fergeau 2006-05-09 16:08:27 UTC
(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
Comment 23 Christophe Fergeau 2006-05-09 16:25:17 UTC
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?
Comment 24 Alessandro Decina 2006-05-09 16:57:45 UTC
(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.
Comment 25 Alessandro Decina 2006-05-09 17:11:32 UTC
(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! 

Comment 26 Christophe Fergeau 2006-05-10 06:41:22 UTC
Btw Alessandro, are you using an arch tree or something for that code? If so, is it publicly available?
Comment 27 Alessandro Decina 2006-05-10 08:12:58 UTC
(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.
Comment 28 James "Doc" Livingston 2006-05-10 12:41:38 UTC
(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.
Comment 29 James "Doc" Livingston 2006-05-14 06:56:07 UTC
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.
Comment 30 Christophe Fergeau 2006-05-14 20:02:55 UTC
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 ;)
Comment 31 Christophe Fergeau 2006-05-14 20:05:13 UTC
Created attachment 65455 [details] [review]
Warning fixes

Goes on top of previous patch
Comment 32 Christophe Fergeau 2006-05-14 20:06:37 UTC
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)
Comment 33 Alessandro Decina 2006-05-15 08:47:57 UTC
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.
Comment 34 Christophe Fergeau 2006-05-15 08:56:45 UTC
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)
Comment 35 Christophe Fergeau 2006-05-16 09:30:21 UTC
Created attachment 65581 [details]
Missing file from the previous patch, attaching it not to lose it ;)
Comment 36 Christophe Fergeau 2006-05-16 11:38:01 UTC
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).
Comment 37 James "Doc" Livingston 2006-05-16 11:43:11 UTC
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).
Comment 38 Christophe Fergeau 2006-05-16 11:45:23 UTC
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.
Comment 39 Christophe Fergeau 2006-05-16 12:26:03 UTC
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'
Comment 40 Paul Drain 2006-05-19 04:34:30 UTC
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'
Comment 41 Christophe Fergeau 2006-05-19 08:36:09 UTC
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 :-/
Comment 42 Paul Drain 2006-05-19 08:45:30 UTC
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?
Comment 43 Christophe Fergeau 2006-05-19 08:59:39 UTC
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)
Comment 44 Christophe Fergeau 2006-05-19 09:06:53 UTC
A tarball generated with make dist doesn't compile here because it's missing rb-ipod.h
Comment 45 Alessandro Decina 2006-05-19 09:59:22 UTC
(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?
Comment 46 Christophe Fergeau 2006-05-19 11:26:37 UTC
(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...


Comment 47 Paul Drain 2006-05-21 08:49:06 UTC
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.
Comment 48 Alessandro Decina 2006-05-21 16:56:44 UTC
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.
Comment 49 Alessandro Decina 2006-05-21 20:56:40 UTC
Created attachment 65967 [details] [review]
updated patch (testsuite included)

forgot to add the testsuite in the previous diff.
Comment 50 Paul Drain 2006-05-22 02:46:45 UTC
Created attachment 65974 [details] [review]
Updates Alessandro's patch to current CVS

Changes the patch to compile against current CVS (the rhythmdb splitup)
Comment 51 Paul Drain 2006-05-22 02:53:49 UTC
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?

Comment 52 Alessandro Decina 2006-05-22 06:57:49 UTC
(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!
Comment 53 Christophe Fergeau 2006-05-22 07:36:47 UTC
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...
Comment 54 Paul Drain 2006-05-22 07:41:11 UTC
(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.
Comment 55 James "Doc" Livingston 2006-05-26 03:10:14 UTC
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.
Comment 56 Christophe Fergeau 2006-05-30 08:56:41 UTC
(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.

Comment 57 Christophe Fergeau 2006-05-30 09:05:14 UTC
Created attachment 66463 [details]
Full log
Comment 58 Christophe Fergeau 2006-05-30 09:12:02 UTC
Created attachment 66464 [details]
Real full log

I screwed up the first time, here is a full one this time
Comment 59 Alessandro Decina 2006-05-30 10:19:17 UTC
(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.
Comment 60 Christophe Fergeau 2006-05-30 11:45:33 UTC
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)
Comment 61 Alessandro Decina 2006-06-09 22:19:24 UTC
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.
Comment 62 Alessandro Decina 2006-06-10 07:56:51 UTC
(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.
Comment 63 William 2006-06-18 17:32:27 UTC
Is it possible to set up the ability to copy music from a daap share to the ipod?
Comment 64 Christophe Fergeau 2006-06-19 10:02:04 UTC
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.
Comment 65 James "Doc" Livingston 2006-06-19 10:43:18 UTC
In theory it should just work, as the ipod doesn't care where it's copying from, and daap->library works.
Comment 66 Alessandro Decina 2006-06-19 11:33:14 UTC
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.
Comment 67 William 2006-06-19 18:26:23 UTC
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.
Comment 68 Alessandro Decina 2006-07-07 20:38:01 UTC
Created attachment 68593 [details] [review]
updated patch

Updated do apply on HEAD
Comment 69 Paul Drain 2006-07-26 08:40:25 UTC
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.
Comment 70 Christophe Fergeau 2006-07-26 08:50:08 UTC
It's not compiling for me because get_db_for_source is defined but not used. #if 0ing it fixes the problem.
Comment 71 Christophe Fergeau 2006-07-26 08:56:37 UTC
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! 
Comment 72 Paul Drain 2006-07-26 09:07:28 UTC
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.
Comment 73 Christophe Fergeau 2006-07-26 09:13:03 UTC
(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"?


Comment 74 Paul Drain 2006-07-26 09:22:12 UTC
(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.


Comment 75 Alessandro Decina 2006-07-26 14:12:45 UTC
(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.
Comment 76 Christophe Fergeau 2006-07-26 14:22:21 UTC
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 :)
Comment 77 Alessandro Decina 2006-07-26 14:43:21 UTC
(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.
Comment 78 James "Doc" Livingston 2006-07-27 08:47:30 UTC
I've committed the RBEncoderGst fix to cvs.
Comment 79 Michel Alexandre Salim 2006-11-12 00:20:26 UTC
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.
Comment 80 William 2006-12-05 17:17:22 UTC
I would like to know this also. I cannot get rb to transcode flac or ogg to mp3 on transfer.
Comment 81 Ben Gamari 2006-12-20 17:32:57 UTC
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.
Comment 82 Alex Lancaster 2007-01-16 07:32:19 UTC
*** Bug 396292 has been marked as a duplicate of this bug. ***
Comment 83 Ed Catmur 2007-02-22 21:18:32 UTC
What's current status on this?  Presumably a lot of the most recent patch duplicates stuff in current SVN rb-ipod-source.c?
Comment 84 Ben Gamari 2007-02-23 00:45:14 UTC
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.
Comment 85 Ed Catmur 2007-02-23 02:33:40 UTC
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.
Comment 86 James "Doc" Livingston 2007-02-23 07:14:40 UTC
(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.
Comment 87 Sebastien Bacher 2007-04-23 13:57:54 UTC
Also requested on https://bugs.launchpad.net/rhythmbox/+bug/109192
Comment 88 Alec Wright 2007-09-14 18:03:21 UTC
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.
Comment 89 Alec Wright 2007-10-09 18:26:56 UTC
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.
Comment 90 Alex Lancaster 2007-10-18 14:35:04 UTC
(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).
Comment 91 Oxmosys 2007-12-04 22:38:07 UTC
Here's a ipod sync plugin made by KittyPee. Maybe that can helps :

http://www.kittypee.com/2007/11/16/rhythmbox-ipod-sync-plugin/
Comment 92 Ed Catmur 2007-12-04 23:39:52 UTC
(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.
Comment 93 Pete Deremer 2008-02-23 18:34:37 UTC
Syncing needs to be included.  It is something that is really bothering me with Rhythmbox.  Its a huge inconvenience
Comment 94 jacques.charroy 2008-04-27 11:24:17 UTC
What's the current status on this? Is real sync implemented yet?
Comment 95 jacques.charroy 2008-04-27 11:27:23 UTC
What's the current status on this? Is real sync implemented yet?
Comment 96 guillermo siliceo 2008-05-26 01:00:53 UTC
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/
Comment 97 Mathijs 2008-05-28 15:23:15 UTC
I'm really waiting for this feature too. Will it be included in the next release?
Comment 98 guillermo siliceo 2008-11-11 06:01:34 UTC
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
Comment 99 John Daiker 2008-11-11 06:38:51 UTC
(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
Comment 100 Christophe Fergeau 2008-11-13 09:59:39 UTC
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.
Comment 101 Jonathan Matthew 2009-09-17 21:22:06 UTC
*** Bug 595484 has been marked as a duplicate of this bug. ***
Comment 102 Jonathan Matthew 2010-01-18 23:57:13 UTC
*** Bug 607387 has been marked as a duplicate of this bug. ***
Comment 103 Tim Hockin 2010-01-19 00:12:48 UTC
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).
Comment 104 Jonathan Matthew 2010-03-29 12:12:12 UTC
I've just merged code based on Paul Bellamy's GSoC 2009 project into master.  iPod sync now works.