Report : http://forum.videolan.org/viewtopic.php?f=13&t=59425&p=198466#p198450

Signed-off-by: Christophe Mutricy <xtophe@videolan.org>

Signed-off-by: Christophe Mutricy <xtophe@videolan.org>

Signed-off-by: Christophe Mutricy <xtophe@videolan.org>

Signed-off-by: Christophe Mutricy <xtophe@videolan.org>

As they need git to be generated, you don't want them to disappear when you do make distclean in sources extracted from the tarball

Close #2754

Actually sort is well done but when the user ask for the next/previous item in
the playlist, it will get the one without the sort and not the right
previous/next item.

This is caused by the fact that the table which describe previous/next isn't
rebuilded after a call to the sort function. This commit force the rebuild to
be done (b_reset_currently_playing = true)

so we must be able to free the memory in this case.

This might help to trac the dmo race.

Close #2682

Should fix #2142

This fix partially #2142

(and add ftp and smb to the list)

 It fixed a segfault when using hotkeys for the OSD.
 I am not sure it is perfectly fine, but var_AcquireMutex seems
to have been removed without a proper replacement.

Should we keep this code?

This should fix the compilation of pda interface.

We want the current playing item, rather than the number of items to
choose from. Besides, item-current is _not_ a choice list anyway.

 One input buffer can create multiples output ones and so need to be fetched
before provided a new input one.

In this case the option is a bit mis-named but...

Spotted by mc2man, mc2man -- optonline | net
(cherry picked from commit e783877897dcafdcd833f81ba44015ccd0ac482f)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

This just in: CeGCC has a MinGW with working replacement *printf
functions. Just like for mingw32, require (and allow building with) a
recent enough version of mingwce.

Since MinGW is patched by CeGCC, this check is not strictly sufficient;
but at least this allows to have working WinCE builds again.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>