I was just writing you an email about libdmapsharing ;) On Thu, Oct 7, 2010 at 20:09, Peter <[email protected]>wrote:
> On Thu, Oct 7, 2010 at 11:59 PM, Peter <[email protected]> > wrote: > > Hi all, > > > > I've recently tried sharing my music from RB 0.12.8 on my server via > > the DAAP plugin, and listening to it with RB on my laptop. This seems > > to work nicely for the most part. However, I noticed that sometimes I > > got cover art, and sometimes I did not. First of all, can anyone > > reproduce this? > > > > I *think* when playing a remote mp3 file which has embedded cover art > > in the ID3 tags that this gets spotted and shown by the cover art > > plugin - which is great, but not all my music has embedded covers. > > > > There is a command in the DAAP protocol to request the current artwork > > with maximum width and height, and get a PNG back. Something like > > this: > > /ctrl-int/1/nowplayingartwork?mw=320&mh=320&session-id=123 > > > > However, I'm pretty sure that the coverart plugin makes no attempt to > > ask the DAAP server for a cover. > > > > From looking at how other plugins (e.g. rb-ipod-source.c) give cover > > art to the artdisplay plugin, I guess the RB DAAP client code needs to > > request the cover and then once it has it, issue the > > g_signal_connect_object call with > > "entry-extra-metadata-notify::rb:coverArt", and it should then be > > displayed by artdisplay plugin. Does that sound right? > > > > Related to this, guess the RB DAAP server code will need to be updated > > to respond to cover requests. Again, looking at rb-ipod-source.c I > > think this can be done with rhythmdb_entry_request_extra_metadata (db, > > entry, "rb:coverArt") which I assume is handled by the artdisplay > > plugin. > > > > Have I got the basics right for how cover art is passed between the > > artdisplay plugin and another plugin (such as the ipod plugin, or in > > future the DAAP plugin)? > > > > Thanks, > > > > Peter > > > > Follow up note to self and future search engine results: if trying to > compile RB from source with the DAAP plugin you will need > libdmapsharing, which isn't in older versions of Ubuntu but is in > Maverick: > > http://packages.ubuntu.com/en/maverick/libdmapsharing2 > http://packages.ubuntu.com/en/maverick/libdevel/libdmapsharing-dev > > Its homepage is here: > http://www.flyn.org/projects/libdmapsharing/index.html > > Repository: > http://git.gnome.org/browse/libdmapsharing/ > > This does appear to serve artwork requested via the nowplayingartwork > DACP command (see dacp-share.c for the code), which is good. > I developed the DACP support as part of my Google Summer of Code project of this year ( http://live.gnome.org/SummerOfCode2010/AlexandreRosenfeld_Rhythmbox) There is some support for nowplayingartwork, but you are going to have two problems: - It's only implemented in libdmapsharing, Rhythmbox doesn't use any of that support. And you seem to be on the right way to implement it in Rhythmbox. - It's part of DACP, not DAAP. And right now, DACP is a subclass of DAAP, while Rhythmbox only uses the DAAP class. Even after my Rhythmbox patch is accepted, it will use separate instances for DACP and DAAP (even though they share almost everything and despite my wishes to use only one instance for both). So you are gonna have to implement ctrl-int handling on DAAP (as in daap-share.c). Should not be too hard since ctrl-int handling is avaliable in dmap-share.c. Good luck, seems to be a really good idea. Regards, Alexandre > > Peter > _______________________________________________ > rhythmbox-devel mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/rhythmbox-devel >
_______________________________________________ rhythmbox-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
