First, VLC Player is a sweet piece of free software, able to play just about any sort of media file thrown at it, unlike certain products I shouldn't mention from Microsoft (*cough* Windows Media Player *cough* *cough*). It's the go-to player for music and video for me.

And with the recent release of version 2.0, some advancements are very welcome.

HOWEVER for some reason the File Input access module no longer has a caching or buffer size setting. That is a huge problem, VLC developers! For those like me who have a media server that shares music on the LAN using SMB file sharing, mounting shared folders as drives under Windows. Sometimes the back-end server gets overloaded with I/O requests and that can cause music or video to stutter, pause, and look/sound bad.

In the past, all I had to do was bump up the caching/buffer size to a very large size, because the server generally can feed the video source just fine so long as the playback client (VLC in this case) buffers enough. But with version 2.0 I can no longer find a buffer/cache setting for the File Input access module. It shows up nowhere.

What gives, VLC?

So now VLC is an awful player if for any reason there's a lot of I/O on my back end server (like, for instance, right now, while my server's ZFS pool is doing a scrub, a very I/O intensive process). Even playing a simple compressed MP3 is stuttering. That's just stupid and poor software engineering VLC folks! Your otherwise-perfect product now has a giant flaw!

Were I authoring a File input module, I'd take a look at how much free system memory was available, pick an input buffer size from a default setting, then watch playback. By keeping track of the buffer's post-start-up high water mark (i.e. the maximum the buffer was ever filled to, up to 100% after playback started, excluding any pre-playback buffer pre-fill), then should we ever bottom-out (the buffer hit zero and playback sutters), I'd automagically grow the buffer size, perhaps double it, if the high-water mark was 95% or higher. I'd reset the high water mark, and watch anew.

That would limit stuttering if the underlying file reads were sporadic (jittery) but the base filesystem was still able to mostly fill the buffer at some point.

So, VLC, why not?

PLEASE fix this! Otherwise I'm going to have to downgrade to 1.x. This one's a deal-killer!

P.S. It turns out a feature request, ticket #2983, was made a long time ago regarding this issue and automating the buffer sizing under the 1.x versions. It is marked as "fixed" with this lame developer cop-out: "This is not fixable on Windows for lack of a statvfs equivalent." Lame! That's not true. One doesn't need statvfs() to keep track of historic buffer input/output rates. It does in fact require more work to implement, and I totally get that this is a volunteer open-source project. But instead of closing the ticket as "fixed" when it is not, it should merely have been left open until such time as someone got an itch to implement it. Annoying ticket closer!