That happened when seeking during the first second of playback.

Never disable Stop
Disable stop when no input
Populate Bookmarks

Don't mix booleans and strings (as non empty strings evaluate to true).

This kills 100 wakeups per seconds.

In principle, this avoids a possible event loss. I am not sure if the
NAV PCI handling is thread-safe here (but it's no worse than before).

We may want to factor some of that marshalling into libvlc later on.

This solves a potential event loss for close events
(especially with the RC interface)

Spotted by courmisch.

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

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

NSMenuItems still exist when libvlc_Quit is called, and thus some items are likely not autoreleased before vlc quits. Set all representedObjects for all menu's to null so that the menuitems no longer retain any of the vlc objects.

When building the menu's, autorelease the VLCAutoGeneratedMenu's instead of retaining. The NSMenuItem will do a retain/release for the live of the object in the NSMenuItem and thus once the menu's are done using the object, their retaincount will be 0 and they will be dealloc'ed at the end of the EventLoop. (An eventloop is One run of GUI updates you might say).

fixup code handles this now.
Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Fixes following issues using MSVCRT _snprintf:
 - Failure to null terminate all strings
 - Failure to return number of characters that would've been
   printed had the buffer been sufficiently large
 - Failure to accept size = 0 (and str = NULL) to determine
   final output length.

NB, the third issue above is fixed on *some* win32 implementations,
however it is not officially documented as being so.
Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>