Re: [Rhythmbox-devel] DACP (iTunes remote) support added

[Peter <rhythmbox-devel maubp freeserve co uk>]

>Peter wrote:
>> The DACP remote expects PNG, and passing JPEG or some
>> other format might cause trouble. A simple check in the non
>> gdk-pixbuf code branch can prevent this (tell the remote we
>> have no cover rather than sending non-PNG data).

Before making a firm choice we should perhaps test sending larger
than requested PNG files, and also JPEG files, to the Apple Remote
application (ideally v1 and v2) to see what happens. It may be more
flexible than we are assuming.

Alexandre Rosenfeld <alexandre rosenfeld gmail com> wrote:
> Hm, I see what you mean now and it's tricky. The application would have two
> choices, either export the right format and the right size to libdmapsharing
> so that it will always support cover art no matter how libdmapsharing was
> compiled or send libdmapsharing any kind of image it gets and let
> libdmapsharing take responsibility for it.
>
> The first is not very good because we would be duplicating the same code in
> the application and in libdmapsharing, with the chance that maybe
> libdmapsharing will not re-convert the image (I would say the chance of
> libdmapsharing not being built with gdk-pixbuf to be quite small. Actually,
> in terms of usage inside Rhythmbox, it will probably always include support
> for gdk-pixbuf, because that is a Rhythmbox dependency).
>
> The second choice will have to check indeed if the file is a valid PNG
> (using the great suggestion from Bastien to use g_content_type_guess, but we
> still wont be able to figure out the dimensions of the image) and so will
> create a chance that certain covers will not show in the client, even if
> available in the host.
>
> I believe the best solution is to make the application make the decision. As
> with Rhythmbox, there is no need to duplicate code, it requires Gtk which
> requires gdk-pixbuf, so in that context libdmapsharing will probably have
> pixbuf support already, so just throw any image to libdmapsharing and let it
> handle it. Any application without a dependency on gdk-pixbuf will have to
> make a decision about what to support.

Yes its a bit tricky. I agree that these are the two clear solutions (1) the
application always gives libdmapsharing a shrunk PNG filename, and
(2) application gives a cover filename and libdmapsharing resizes
converts it to PNG.

However, I would say the best solution is the second one as is avoids
creating a temporary file on disk (for the shrunk cover converted to PNG).
In RB at least, all the cached cover files (which is what my patch seems
to pass to libdmapsharing) are currently saved as JPEG.

Also the first solution could be seen as a break in backwards compatibility
of the libdmapsharing API (currently it will take JPEG filenames).

Peter