VLC takes long time to start playing a video file given as GVFS path in a directory containing a lot of files

[Jarno Suni]

If I try to play a video file that is located in a directory containing a few files in a network storage, starting playback takes long time. Path used for such a file start by $XDG_RUNTIME_DIR/gvfs. While it is trying to start to play the file, vlc does not respond, if I order it to quit. Even killig by signal 1 or 15 fails, but I can kill it by signal 2.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: vlc 2.0.8-1
ProcVersionSignature: Ubuntu 3.11.0-14.21-generic 3.11.7
Uname: Linux 3.11.0-14-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.2
Architecture: amd64
Date: Wed Dec 25 14:16:21 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-09-20 (96 days ago)
InstallationMedia: Lubuntu 13.04 "Raring Ringtail" - Release amd64 (20130423.1)
MarkForUpload: True
SourcePackage: vlc
UpgradeStatus: Upgraded to saucy on 2013-10-18 (67 days ago)

[Rémi Denis-Courmont (rdenis)]

If VLC is locked up, we need a threaded stack trace of when it is locked up.
(If on the other hand it is stuck in uninterruptible state, then it is a kernel bug.)

[Jarno Suni (jarnos)]

How would I know?

[Mantas Kriaučiūnas (mantas)]

Could you test if your problem with VLC is not fixed in latest upstream version (2.1.1)?
You can install VLC 2.1.1 from ppa:dirk-computer42/c42-backport

See https://launchpad.net/~dirk-computer42/+archive/c42-backport for more info about installing.

[Jarno Suni (jarnos)]

No that does not fix it. If I connect to a windows share in Gigolo or in Nautilus, and launch VLC to play some video in the music folder, the delay occurs. However, if I mount the samba share as a cifs file system in /etc/fstab, VLC starts playback in much shorter delay.

[Launchpad Janitor (janitor)]

[Expired for vlc (Ubuntu) because there has been no activity for 60 days.]

[Rémi Denis-Courmont (rdenis)]

Can you please paste the VLC verbose logs ('vlc -vv') and the output of the command 'mount' while reproducing the problem?

[Rémi Denis-Courmont (rdenis)]

This is not a Samba share. This is a userspace filesystem that is insanely slow at listing directory content. In other words, this is a performance problem inside GVFS.

You should rather avoid GVFS. Either mount the SMB filesystem natively (with kernel CIFS support), or supply VLC with the original smb:// URL.

[Jarno Suni (jarnos)]

No, if it was a GVFS bug, it would occur also when I request Kaffeine to play the file. In the bug report I did not tell anything about the speed of listing directory content. I did not ask VLC to list files in the directory, but to play a file that is located there.

The bug may occur when I browse files in Thunar file manager (1.6.3) and use "open with" feature to play a file by VLC. Effectively, Thunar adds a path under /run/user/ as an argument for VLC or Kaffeine. If I use PCManFM (1.2.0) to "open with", a smb-url is used, instead, and then VLC does not have such a delay before playback. On the other hand Kaffeine can not play such a smb-url.

The bug still exists in VLC 2.1.4-0-g2a072be

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Rémi Denis-Courmont (rdenis)]

This is a GVFS bug. This bug will not be processed in upstream VLC.

[Jarno Suni (jarnos)]

Then how do you explain Kaffeine can play same command line argument promptly?

[Rémi Denis-Courmont (rdenis)]

Either Kaffeine does not scan the containing directory for local files, which VLC needs to do to detect subtitles, or Kaffeine gets the SMB URL instead of a path to a GVFS mount.

As far as I can tell, the problem is that enumerating the content of a directory from the GVFS mount is insanely slow.

[Jarno Suni (jarnos)]

Kaffeine gets the same path to a GVFS mount as VLC. Listing the files of a directory by ls takes about 4 seconds. The delay before playing a file in the directory takes about a minute.

[Jarno Suni (jarnos)]

I disabled "Autodetect subtitle files" in VLC settings, and thereafter there is no such delay.

[Jarno Suni (jarnos)]

Could subtitle autodetection be optimized so that VLC would be more responsive? Another option is to disable autodetection by default.

[Rémi Denis-Courmont (rdenis)]

There are no ways to optimize directory enumeration so long as GVFS hides the directory behind CUSE. "Local" filesystems cannot be polled, VLC will get stuck in kernel space for however long it takes GVFS to generate a result.

The only way to fix this on VLC side is to supply the SMB URL instead.

[William Pietri (william-launchpad-net)]

Perhaps VLC could by default start playing without having discovered whether subtitles exist? That wouldn't eliminate the problem, but it would be experienced by a much smaller group of people, and the problem would go from "video doesn't play" to "sometimes subtitles take a while to start", which would be lower impact.

[Wihola IT (wihola)]

It was MAY 2016, VLC still needs numeros time to get started. And than it starts with over9000 instances. I wonder whose bug is it, VLC's or Ubuntu's?