Fix a busy loop and socket leak. Thanks to Santiago Gimeno for
pointing it out (Debian bug #607869)

This reverts commit a1b3978d.

It doesn't fix anything and it breaks new connections
Signed-off-by: Pierre Ynard <linkfanel@yahoo.fr>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Oked-by: Laurent Aimar
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

pub   1024D/45C11CA7 2011-01-30 [expires: 2012-01-30]
      Key fingerprint = 160A 96C4 CA7F 8ABA D43C  C087 62B9 7F54 45C1 1CA7
uid                  VideoLAN Release Signing Key (2011)

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

This affects way too many code paths. Let KDE fix their own crap.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

This fixes cases where the stream length is unknown

Otherwise, when sending requests while already receiving data
(e.g. seeking) responses are not waited for properly

This reverts commit 7b18ec43.
This broke LibVLC and wall.

This reverts commit 95b63292.
This broke LibVLC and the wall filter.

Same rationale as previous patch about Linux.

fix trac #4440 (to be tested)

When the default window provider is used (dummy, rc, ... interfaces),
rather decide what to do when the user closes the video window than let
the WM blindly destroy it. Till now, this led to an error message, input
dying and the playlist being stopped. For -I dummy, it also meant leaving
vlc hanging since no interface could then be used to stop vlc.

Action taken is to stop vlc, but feel free to change/improve/make it
more configurable if need be.

An negative integer would make no sense here. I guess we could use an
unsigned char here, since it can only be between 0 and 127, as far as I
understand