This fixes the reading of CDDB information by not setting INPUT_CAP_BLOCK
for the CDDA plugin (and therefore also setting CD_RAW_FRAME_SIZE to 0), and
allow reading in non-block sized chunks as per
http://hg.debian.org/hg/xine-lib/xine-lib?cmd=changeset;node=a470c338149c;style=gitweb

Explanation: At some point a number of releases ago, a codepath in Xine
related to the reading of block devices which had been bypassed was fixed,
which meant that when certain frontends asked Xine to provide CDDB
information for a disc, querying the name, length, etc.  of each track, Xine
would actually cause a seek to the starting block of each track, which meant
that before starting to play, the player would pause for 5-10 seconds,
seeking through each track.  This is unnecessary, since Xine should have
simply used the CD TOC information from the CD audio header at the start of
the disc.  Other frontends handle CDDB differently and don't query Xine for
information track by track, and so never triggered this problem.  But for
those with the problem, it made loading a disc rather slow.

It turns out that the root of the problem is that the CDDA plugin shouldn't
be setting INPUT_CAP_BLOCK, since Audio CDs are not block devices _in the
sense that Xine intends_.  Simply turning this off fixes the problem, with
no other side effects (tested locally, for some time now, on xine-ui, kscd,
kaffeine, amarok, etc.).

This change pairs nicely with a patch originally committed years ago (cset
a470c338149c) but which was reverted as it inadvertently triggered the same
problem as is now (properly) fixed by the simple above-mentioned change.
Now that a better fix is in, it can be re-committed.

This code is returned when there is more than one CDDB entry for the disc in
question. Before, when receiving a 211 response from a CDDB server, Xine
would simply not display any CDDB information. Now one of the responses is
displayed, on the theory that something is better than nothing.