On Tue, Oct 26, 2010 at 12:21 AM, Peter wrote: > On Mon, Oct 25, 2010 at 4:32 AM, W. Michael Petullo <[email protected]> wrote: >> Peter wrote: >>> The following stub entry in libdmapsharing to just say we don't >>> have covers (rather than not handling the request at all) seems >>> to solve the stale cover issue I was seeing in the Remote app: >>> ... >> >> Applied to libdmapsharing Git master. Please test. > > Thank you Michael - that works for me. > > With the latest libdmapsharing from git, the attached patch to > RB's DAAP/DACP plugin works nicely to support the now > playing artwork/cover in the Apple Remote application. > This includes the helpful comments from Bastien yesterday. > > As discussed earlier, full over support via DACP will need > a new API call added to libdmapsharing. >
Hi Michael, I've been able to send covers (using a single hard coded filename) by inserting a copy of the dcap-share.c cover sending code into dmap-share.c in this new stub. However, I don't understand the libdmapshare code enough to work out how to define the callback function which would ask the client (in this case the Rhythmbox plugin) to supply the appropriate filename. It would then make sense to make the code which takes the cover filename and turns this into the soup message into a shared function. Note that when HAVE_GDKPIXBUF is false, I think it would make sense to check the file really is a PNG (and not JPEG) before sending it to the remote client. This could be as trivial as checking the filename extension (since this is the branch when we don't have the graphics library). Regards, Peter _______________________________________________ rhythmbox-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
