The VideoLAN Forums

I'm not 100% sure that this is a VLC issue, but when playing back video from a smb share over wifi, I experience frequent (frequent enough to be annoying) pauses/lag during playback. When copying the same file with the same network configuration, I saturate the connection at a consistent 70mbps. After looking at network activity, it looks like VLC or whatever application happens to be playing back the video gets part of the video at full speed, and then completely stops buffering (not sure if its the right term) until the video pauses/lags, and then it immediately starts to buffer another chunk of the video. Is this something that I can change in VLC, or is it some weird bug in Apple's samba replacement, or god forbid the behavior is built into the networking stack itself.

Any insight would be greatly appreciated.

Preferences > Show All

On the left panel make sure Input / Codecs is selected. Scroll down in the right panel until you get to the Advanced section. All of the default caching in here is set to 300ms. I changed all of them to 10000ms (10s) and the skipping problem went away.

Hope that helps.

Sorry to bring up an old post, but I had the same issue, tried your solution and it only made the buffer issue take longer, from tens of seconds to a couple of minutes. Any other suggestions?

This was fixed for VLC 2.2, which should be out in a few weeks from now.

As of 25 Sep 2014 with VLC 2.1.5 on Mac OS-X 10.9.4 this is not fixed. I have the same behaviour as the OP when watching video over network from an SMB share; viz

10 Playback works fine - but no data downloaded while playback in progress.
20 Playback freezes for a while (few secs to a minute or so)
30 Data are downloaded at rates between 3MBPS to 8MBPS for a while (few secs to a minute or so)
40 Playback starts
50 Data download stops (I mean - zero)
60 Goto 10

VLC is not buffering while it's playing. Increasing the cache size makes the pauses last longer.

Will it ever be fixed?

Please try this pre-release build of VLC 2.2.0: https://www.dropbox.com/s/r39ona7ykqilw ... 3.dmg?dl=0

That pre-release build fixes this for me.

It's a lot better, but it still freezes when it runs out of data. Same symptoms - while playing it loads bugger all data at a few BPS then, when it's frozen, it grabs a load at 3-6MBPS. The freezes are a lot further apart with his pre-release but it still needs work.

It's a lot better, but it still freezes when it runs out of data.

What should it do instead, if no data is available?

If your connection speed is considerably too low, you cannot do much. Although, you can try to increase the caches to buffer short-term drops.

It should buffer so it doesn't run out of data, shouldn't it?

The behaviour is that while it's playing the download rates are tiny - in the range of few bytes per second to (rarely) a kBPS. After a while playback freezes and then it downloads a chunk of data at rates between 3 and 8MBPS - available data rates are fine. Then it starts playing again and as soon as playback re-starts the download rate plummets back to the few BPS range as described above.

Setting the cache size bigger just makes the freezes last longer, presumably because it has a bigger buffer to fill and for some reason VLC appears to fill its buffer only when it's not actually playing.

There's no doubt that this build is massively better because the previous build download zero BPS when it was playing and I can live with it.

Thanks for replying and if you were part of the team that developed this build then thanks for that too.

BTW - instead of my speculating from a very weak technical position about what VLC is doing - here's what the log says when there's a freeze in VLC playback. The following is a cut and paste from the log immediately after three short freezes which all occurred within the space of a couple of minutes.

core error: \cf4 ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 14071 ms ignored)\
\cf2 core warning: \cf3 playback way too early (-1998446): playing silence\
\cf2 core debug: inserting 95925 zeroes\
core error: \cf4 ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 14575 ms ignored)\
\cf2 core warning: \cf3 playback way too early (-1997660): playing silence\
\cf2 core debug: inserting 95887 zeroes\
core error: \cf4 ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 15744 ms ignored)\
\cf2 core warning: \cf3 playback way too early (-1997774): playing silence\
\cf2 core debug: inserting 95893 zeroes\

Let me see if I can attempt to explain the bug better:

Upon initial playback, VLC buffers a large chunk at a fast rate up front. One would expect that as VLC is playing through the buffered content, it would continue to download at the rate of playback to ensure the buffer is constantly filled with fresh content. However, VLC does NOT continue downloading during playback. After a few minutes, when VLC has played through the entire buffer, VLC has to stop playback while it refills the buffer with new content since it has not been doing so during playback.

It is definitely not a network problem, since when VLC does download, it does so at a fast rate.
My guess is that VLC (or OSX's samba mount) uses a naive chunked buffer instead of a circular buffer.

Hi dleedev. You've summed up the symptoms perfectly.

I don't think that VLC does the downloading directly. When VLC is playing it hovers at the top of the CPU usage list. When VLC stops playing it drops way down the list and a kernel task hits the top when downloading starts in earnest.

I guess (I'm not a softie) that VLC attempts to get round this problem by having the ability to set its internal cache separately, but in this case it seems not to be working because increasing the VLC cache makes the freezes last longer (presumably because it's got more buffer to fill). It looks as though the trigger for when the kernel process should start to download is coming from when VLC buffer is empty - rather than when the buffer starts to be consumed.

Hello

I have the same issue.
I have tested it on VLC 2.1

I have also downloaded 2.2.0 Pre 3 as adviced by Felix Paul Kuehne and I have set all netrork caching other 3 caching in advanced section to 10000ms.
Video is definitly buffering longer, but it's still lagging after a while ;/

I am runing from windows 7 smb share over wifi.
I have noticed is that video file is propably buffered to slow - while playing video Task manager shows network usage 2-4Mbs but when copying the video it usually goes 50-60Mb\s (4-6MB\s). Copying whole 2GB video file takes about 15-20min. This clearly proofs that 90min video sould be easly buffered druring playback, becosue there is a lot of spare brandwitch but as task manager shows video is buffered to slow.
Important Hint I have also noticed that when I am copying file over smb wifi it usually goes 50-60Mb\s but when I start to play video (from local very fast Vertex 4 SSD Drive) file is copied much slower 350-700b\s over sbm. This happens while playing video in VLC player and windows media player so the problem may be in some system setting. Only way to speed up copying is to close video player. After oing so transfer goes back to 50-60Mb\s

Configuration:
1. Procesor laptop wirh 2nd gen core i5, about 20-30% usage
2. 8GB Ram, 6GB free
3. Win 8 x64

Any suggestions?

Hi Felix Paul Kuehne
I had the same problem that Pienamics has been explaining..

Using your posted V2.2.0 pre3 solved my problem..
Thank you very much..

@Besbes: thanks for the heads-up. Happy to hear!

I can confirm this. Just opened a thread there (https://forum.videolan.org/viewtopic.php?f=12&t=123453).

I monitored the upload/download rates of my NAS setting the cache to 60000ms. VLC at first buffers in the beginning with rates about 12 Mb/s from my NAS (via wifi). Soon later the transfer rate drops to 0 (zero) Mb/s and restarts several seconds later. So it seems VLC is not continuously filling the buffer in the background while playing back the video.

I followed Felix Paul Kuehne's advice and tried the 2.2.0 RC2 and the problem still persists. I am under Yosemite (!!) with VLC 2.2.0 RC2 now and still not able to play back a 1080p HD movie. Again, downloading from the smb share gives me 13 Mb/s download speed. Even when I set the network buffer to 60000 VLC is fetching it's data with a lousy 1.4 Mb/s (doesn't make sense)- and it is not going beyond this. No wonder the buffer runs out with a 14 GB HD movie. Anyways if you'd need logs of something just tell me.

Just something I came across: in XBMC/Kodi there's a parameter (readbufferfactor: Increase the fill-rate of the cache) which tells the player whitch bandwidth it should use. It will never be possible to play such a file if VLC will not make use of the necessary bandwith.

The question is "why is VLC buffering so slow?". VLC needs to be more 'aggressive' to keep it's buffer filled! How can a buffer of 10 seconds movie suddenly stop when a bandwith of 13 Mb/s exists?

EDIT:
here you can see this:

here is the log file. It takes VLC some 8000 ms to buffer 10000ms, copying the movie would take 30 minutes, so definitely there is something wrong with the buffering...

hmmm....the problem seems to exist since 2013 already. That's bad...(http://archiv.raid-rush.ws/t-845171.html)

Sorry to bother with this problem, but we have over 8000 views here and nobody is able to say something about this problem? What else should I post to try to find the problem?

Someone who understands this issue. It is complex, since smb is done by the OS.

that's true, but when I copy the whole amount of data I get 13 MB/s, so what I don't understand is why the VLC Player doesn't request enough data to not run out of buffer as it is definitely possible for the network? SMB is not responsible for the buffering, isn't it? The result is the same when I choose AFP instead of SMB.

Interestingly I've tried giving VLC highest priority and either closing or demoting other processes in an attempt to improve its performance. It makes no difference.

Even more interestingly is the speed of response from VLC staff on this thread when someone posts how great their product is but the complete lack of response to the freezing problem which is a pain for a lot of us. If the developers are not going to fix this problem I'd prefer it if they just told us - although I guess we can take the hint.

BTW - I got a new MBA and moved to Yosemite and it's still the same. I haven't used VLC for a while now because of this problem. I'm using the Mac native DVD player for the formats it supports and I've been re-recording the DVDs which I've only got in VOB format so that I can use the native player instead of VLC - which I've had to give up on because of this freezing problem.

The Mac DVD is better player anyway because the "start from last position" feature works, unlike with VLC. Much nicer FFWD too. If they added an audio advance/delay feature it would be my goto player.

Even more interestingly is the speed of response from VLC staff on this thread when someone posts how great their product is but the complete lack of response to the freezing problem which is a pain for a lot of us. If the developers are not going to fix this problem I'd prefer it if they just told us - although I guess we can take the hint.

People are volunteers. They do what they can...

A complex problem that noone can reproduce, give enough info or solve is useless to answer to.

SMB access is done by the OSX kernel, not VLC code.