releasing it. mutex locks /= 20 on a standard preparse run
* Only create absolutely necessary variables while preparsing
--> Preparse speed *= 4 (with item in disk cache of course)

* Do not rebuild playlist too much while adding a directory. Add a new flag
  to NodeCreate and Add to control this behaviour

For some unknown reason, wxwidgets 2.6.3 always return WXK_NUMPAD_DELETE
even in case normal Delete key was pressed

Please consider backporting just for Win32 binaries.

Fix m3u export

This might not fix it, but it surely should eleviate the problem.
forwardport of [18324]

  - fspanel centering on right screen
  - fspanel don't hide if mousepointer is over fspanel

DISCLAIMER: libgcrypt includes various strong cryptographic ciphers.
VLC now has 256-bits ciphers, and already had 128-bits ciphers for some
time. Please check with your lawyer and country-specific homeland
security bureau. In France, *usage* is completely free. Supply, import
and export are not.

 - rationalize var_CreateGet*() and config_Get*() usage

...when the lower layer failed (ie TCP or SSL errors)

FIXME FIXME FIXME FIXME: EXPLICIT HACK.
On the one hand, we cannot hold the lock while triggering a callback, as
it causes a deadlock with video-on-top handling. On the other hand, we
have to lock while triggering the callback to:
 1/ make sure video-on-top remains in sync with fullscreen (i.e.
    unlocking creates a race condition if fullscreen is switched on and
    off VERY FAST).
 2/ avoid possible corruption bugs if another thread gets the mutex and
    modifies our data in-between (though it does not seem like it could really
    do much harm in this particular case).

This is obviously contradictory. Correct solutions may include:
 - putting the fullscreen NAND video-on-top logic out of libvlc,
   back into the video output plugins (ugly code duplication...),
 - serializing fullscreen and video-on-top handling properly instead of
   using the fullscreen callback. That's got to be the correct one.