Video playback over smb skipping/lagging

[mpt]

Wow, I can't believe the time span of this thread. Can confirm same issue: Windows 10 x64, vlc 3.0.4, usb 3.0 drive containing media files attached to usb port of RTA1300M router.

[JeffLakela@Yahoo.com]

Similar behavior can be seen when trying to playback from a DVD/CD drive -- it appears as though a read-ahead buffer runs empty, forcing the video to stop. Increasing the caching time only delays the problem.

[XorZy]

I'm also having the same issue when playing a video over SMB.
However, decreasing the caching time to 50ms seems to have helped.

[Fidik]

Hello,
my videos are saved on an external HDD connected to RPi2 with LibreElec. When I connected to it via SMB from Win10 ntb, I had also the problem with lagging of the videos.
Setting cache to 10k ms kinda helped for me. The video is loaded in a few secs, the same for skipping. Overall, it plays fluently, tested up to 1080p mkv.
Thank you
F

[Killom]

I can confirm, this issue is still around in 2019 - and not a "MAC OS only" thing this is a general flaw, deeply buried within VLC's network code

I wouldn't be surprised, if this issue can be reproduced even with the Android App. (Will test this somewhat later the day)

My Setup:
VLC 3.0.7.1
Host: Server 2008 R2
Client: Win 10 1809

Networkshare on Host is accessed over VPN.

Buffering stutters occur every other second when playing back silly FLAC files.
Playback with MPC-HC is working like a charm. So this is no bandwidth issue

Code: Select all

[00000279883a6910] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 5043 ms ignored) [00000279883a6910] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 5063 ms ignored) [00000279883a6910] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 5009 ms ignored) [00000279883a6910] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 5984 ms) [00000279883a6910] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 9379 ms ignored) [00000279883a6910] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 5093 ms ignored) [0000027988516cc0] main decoder error: Timestamp conversion failed for 104675556: no reference clock [0000027988516cc0] main decoder error: Could not convert timestamp 0 for flac [00000279883a6910] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 5072 ms ignored) [00000279883a6910] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 5045 ms ignored) [00000279883a6910] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 5045 ms ignored) [00000279883a6910] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 5085 ms ignored) [00000279883a6910] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 5085 ms ignored) [00000279883a6910] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 5071 ms ignored) [00000279883a6910] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 5034 ms ignored)

After adjusting jitter option to -1:

Code: Select all

[00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 153 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 93 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 114 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 114 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 133 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 152 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 133 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 133 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 133 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 133 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 80 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 79 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 79 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 80 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 87 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 156 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 156 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 85 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 41 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 41 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 52 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 52 ms ignored) [00000279883a55f0] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 103 ms ignored) [0000027988516cc0] main decoder error: Timestamp conversion failed for 21640998: no reference clock [0000027988516cc0] main decoder error: Could not convert timestamp 0 for flac

@Staff: You can contact me via my via the stored email address in my profile - for more information and debugging support

[Louderme]

please follow some steps and solve vlc smb skipping/lagging problem

1) First, open VLC’s preferences by going to Tools > Preferences.

2) Then, click “All” under the “Show Settings” option at the bottom of the window. Click “Input / Codecs” in the left sidebar.

3) If the file that is skipping is playing from a local hard drive, look for the “File Caching (ms)” option under “Advanced” on the right-hand side. The caching value here is set in milliseconds, so setting the value to 1000 will buffer for 1 second (the default is 300, or 0.3 seconds). The problem setting this option to is that if you want to manually skip to a new point in the file, there will be a larger lag while the content is buffered again.

4) If the file you are trying to play is located on a network share, you can change the caching value for “Network Caching (ms)”.

5) For illustration, I’ve shown the value set to 1 second, but this setting can be used to buffer as much as you want, whether it’s 5 seconds or 20 seconds. However much you need to eliminate the skipping on your network.

[Eld0r]

is known but only delays the time to video lag for a samba network share.
if network is good, like in same gbit network, there are nearly no lags. none, with optimized "Network Caching (ms)".
if conenction is a bit slower in ping and speed, like a vpn, there is a lag every "Network Caching (ms)" time.
Monitoring the connection you'll see network traffic spikes every now and then (around "Network Caching (ms)" time) and high throughput alternating with long times of 0 mb/s inbetween.
(Note that this is the case even if the network speed capacity exceeds the max video bitrate by 3 or more times).

[DarkSwordsman]

Hi everyone. I also found this thread after googling for my own SMB + VLC issues.

I currently run my SMB through Hamachi. My search started there because I thought it was a Hamachi issue. Messing with MTU and capture size has seemed to helped some people with this, however, it was bigger than that since SMB apparently has issues with latency [url=https://www.mirazon.com/issues-with-smb-file-transfer-performance-over-vpn]as explained here[/url].

It says, "But at its core, SMB is limited by being a block-based protocol. FTP and others will stream the data. SMB is built to constantly chat back and forth with the file server."

I was trying to share an SMB folder with someone over the Hamachi VPN. The latency was in the 90-110ms range over a significant distance across the US. This was not only causing buffering, but made the image look grossly pixelated [url=https://i.imgur.com/jSoLJlm.png]like this[/url].

I tried the local cache size trick, which we increased from 1000 to 4000, but that didn't help too much.

However, I was looking at "Clock Synchonization" since it said, "It is possible to disable the input clock synchronisation for real-time sources. Use this if you experience jerky playback of network streams."

Disabling this appears to have almost completely solved the issue. Apparently there's still some slight pixelation when you press the "play" button, but it will continue to play the video and doesn't hang from buffering.

Of course this was testing over only about 5-10 minutes, so if we run into more issues, I'll update here. However, this seems to have at least mostly solved the issue.

Edit: Not sure why URLs aren't working...

[maxbraketorque]

Hi everyone. I also found this thread after googling for my own SMB + VLC issues.

I currently run my SMB through Hamachi. My search started there because I thought it was a Hamachi issue. Messing with MTU and capture size has seemed to helped some people with this, however, it was bigger than that since SMB apparently has issues with latency [url=https://www.mirazon.com/issues-with-smb-file-transfer-performance-over-vpn]as explained here[/url].

It says, "But at its core, SMB is limited by being a block-based protocol. FTP and others will stream the data. SMB is built to constantly chat back and forth with the file server."

I was trying to share an SMB folder with someone over the Hamachi VPN. The latency was in the 90-110ms range over a significant distance across the US. This was not only causing buffering, but made the image look grossly pixelated [url=https://i.imgur.com/jSoLJlm.png]like this[/url].

I tried the local cache size trick, which we increased from 1000 to 4000, but that didn't help too much.

However, I was looking at "Clock Synchonization" since it said, "It is possible to disable the input clock synchronisation for real-time sources. Use this if you experience jerky playback of network streams."

Disabling this appears to have almost completely solved the issue. Apparently there's still some slight pixelation when you press the "play" button, but it will continue to play the video and doesn't hang from buffering.

Of course this was testing over only about 5-10 minutes, so if we run into more issues, I'll update here. However, this seems to have at least mostly solved the issue.

Edit: Not sure why URLs aren't working...

I've found that disabling clock synchronization prevents VLC from stuttering every few seconds, but it still pauses periodically. The period between pauses seems to be related to the time value for the network connection cache, but it seems to be longer than that value, maybe by 2-3x. This is over a permanent network-to-network VPN connection with a ping time of 40-45 ms and file transfer speed of ~4 MB/s from the SMB server. I'm amazed at how long this issue has existed. I've been periodically revisiting it for at least the last 5 years, and its still not fixed when it should have been fixed long ago because there is no reason why any stuttering or pausing should occur over a connection with that kind of capability.

[kopetepanda]

Are any of the VLC devs alive ?? This is a really bad bug thats been hanging around since 2013.. @Felix paul kuehne @dfuhrmann

[ePirat]

I've tried it and I can play Videos over SMB flawlessly so I am not sure what the problem is. On macOS VLC completely relies on the macOS SMB integration so if it does not work well, thats likely a problem in macOS or with the SMB server usually.

Can you provide more information about the issue? A lot of the posts here seem to be about Windows which uses a completely different SMB implementation inside of VLC. (While on macOS, the SMB content just looks like any other file you have locally)

[Jamato]

I seem to be experiencing this issue with WIndows 10 x64 hosting videos and android app v3.2.12 trying to play them. Increasing Network Caching value to 5000 didn't help. The stream lags way too often. Playback just pauses, then does nothing for awhile, then comes back from... uh... corrupted or partial keyframe I'm assuming?

[Eld0r]

Can you provide more information about the issue? A lot of the posts here seem to be about Windows which uses a completely different SMB implementation inside of VLC. (While on macOS, the SMB content just looks like any other file you have locally)

Well if you are in an <1ms gbit environment it doesn't matter.
But if ping is a bit higher and mbits not that high (because of a Wifi bridge or a VPN) then watching mkv videos suck. Even videos with around 4-6 mbit/s lag in regular time spans for a connection with more than 30 mbit/s througput. When you have a look at the routers traffic graph while watching the video: you wait until first loading in VLC video with a peak in traffic graph. Afterwards video runs fine and traffic graph slopes down to 0. Then video pause again with a loading spike and it repeats.
It's getting worse the higher the buffer is set to. But the time between lags increase for higher buffers.
Are you guys sure you are correctly preloading the next buffer intervall in your windows implementation?
Don't blame you on a < instead of a ≤ loop or sth like that ^^ or maybe just add one more buffer inverval.

[d4rky89]

EDIT
Just saw that this thread is in the macOS Troubleshooting forum (landed here through a websearch).
I'm have this issues with Windows10 and VLC version 3.0.11.
So my post can be found here now:
https://forum.videolan.org/viewtopic.ph ... 20#p508820
/EDIT

Regards, d4rky

[ShamblerDK]

Just discovered this exact issue on 3.0.16.

Even Windows Media Player plays these files without issues. How has this not been fixed in VLC yet? Seems kinda trivial and ridiculous.

Thousands of pieces of software out there handles buffering on the fly just fine...

[ePirat]

Hi, this is the wrong place if you encounter this issue on Windows, as this is the macOS specific section of the forum.

[ortegacomputacion]

I just registered to say this is not a windows issue, it happens in Mac OS High Sierra as of May 16, 2022 , and no, it hasnt been fixed yet, and yes, it does seem to appear in windows too. only common thing I can think of is samba NAS and VLC, so the issue is OS agnostic.

[Pienamics]

8 years since my original post and this is still a problem. VLC has moved on to 3.0.17 and I've moved on a couple of MAC OS's to Big Sur - but still I have to download DVDs from my NAS to my hard drive because even with the MAC hard-wired on Ethernet playback still pauses every minute or so while VLC downloads from the NAS.

Behaviour is the same as before. While the video is playing VLC downloads sporadically at a few kb/s. Then the video pauses and it downloads at about 24Mb/s until it starts again, at which point it reverts to downloading at a few kb/s. Increasing the caching in Preferences just makes the pauses further apart and last longer.

The native DVD player works fine.

8 years.

[Eld0r]

iirc VLC 2.2.8.0 did a somewhat decent or let's say at least a better job than 3.0+.
It does work fine with a single digit ping gigabit connection but whenever you go below hundred megabit and add some latency VLC sucks and you better use media player classic as they manage to perfectly balance the transfer to the buffer.