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

Bug #1264102 reported by Jarno Suni on 2013-12-25
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
vlc (Ubuntu)
Undecided
Unassigned

Bug Description

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)

Jarno Suni (jarnos) wrote :
Jarno Suni (jarnos) on 2013-12-27
description: updated
Jarno Suni (jarnos) on 2013-12-27
description: updated
summary: - Does not play some files from a folder in samba share even if Kaffeine
- plays them from there
+ Does not play some files from a folder in samba share without a several
+ minutes long delay even if Kaffeine plays them from there right away

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.)

Changed in vlc (Ubuntu):
status: New → Incomplete
Jarno Suni (jarnos) wrote :

How would I know?

Mantas Kriaučiūnas (mantas) wrote :

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) wrote :

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) wrote :

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

Changed in vlc (Ubuntu):
status: Incomplete → Expired
Jonas Juodė (jonukas) on 2014-03-27
Changed in vlc (Ubuntu):
status: Expired → New
Rémi Denis-Courmont (rdenis) wrote :

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

Changed in vlc (Ubuntu):
status: New → Incomplete
Jarno Suni (jarnos) wrote :
Jarno Suni (jarnos) wrote :
Jarno Suni (jarnos) wrote :
Rémi Denis-Courmont (rdenis) wrote :

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.

affects: vlc (Ubuntu) → gvfs (Ubuntu)
Changed in gvfs (Ubuntu):
status: Incomplete → New
summary: - Does not play some files from a folder in samba share without a several
- minutes long delay even if Kaffeine plays them from there right away
+ gvfs takes ages to list SMB directory content from VLC

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) wrote :

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

Changed in vlc (Ubuntu):
status: New → Confirmed
Jarno Suni (jarnos) on 2014-11-03
affects: gvfs (Ubuntu) → vlc (Ubuntu)
Jarno Suni (jarnos) on 2014-11-03
summary: - gvfs takes ages to list SMB directory content from VLC
+ VLC takes long time to start playing a file given as GVFS path

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

Changed in vlc (Ubuntu):
status: New → Invalid
Jarno Suni (jarnos) wrote :

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

Rémi Denis-Courmont (rdenis) wrote :

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) on 2014-11-04
summary: - VLC takes long time to start playing a file given as GVFS path
+ VLC takes long time to start playing a video file given as GVFS path in
+ a directory containing a lot of files
Jarno Suni (jarnos) on 2014-11-04
description: updated
Jarno Suni (jarnos) wrote :

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) wrote :

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

Jarno Suni (jarnos) wrote :

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) wrote :

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.

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) wrote :

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?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers