[Bug] Can not exit vlc properly when you close the app while playing

[Rémi Denis-Courmont]

There's nothing special about VLC when it comes to debugging on Linux. I think everybody uses GDB.

[regulator]

Here is my stack trace:
[url]https://pastebin.com/qiEct8iw[/url]

[Rémi Denis-Courmont]

Different driver, same problem: GL driver stuck waiting for event in XCB. I don't know Mesa internals, but I guess it's some missing error handling.

[regulator]

is there any further info you can provide that I can relay to the mesa team?

[Rémi Denis-Courmont]

I cannot reproduce the problem here.

If you're using the stand-alone VLC video window, Mesa might just freeze as it does not handle dead X connections. By comparison, if you use the integrated video window, then the Qt UI will forcefully abort the VLC process.

[kosal75]

I've had the some problem for a few months now, and I've just recently checked this forum.

It really helps to stop the video and then quit vlc, however it should not be the solution.

Is it for sure an intel driver bug? I don't think so.

AMD A8-7600 Radeon R7, 10 Compute Cores 4C+6G

Ubuntu 19.10 with stack kernel 5.3.0-40.

[ieleja]

Debian Buster up-to-date
i7-8700K, 32 GB RAM
AMD RX-570 video

usually I start VLC from file explorer, click on video, if I try to stop with mouse on windows close button (x), VLC visual closes, but about ~30 VLC processes stays in memory, before killing em all, VLC don't run
if I use Ctrl-Q, VLC closes properly

if I forget to use Ctrl-Q, I use:

Code: Select all

killall -9 vlc

[Rémi Denis-Courmont]

Is this with UI-embedded video or separate video window?

[ieleja]

it is with seperate, standalone VLC window

VLC version is 3.0.8 Vetinari
(https://packages.debian.org/buster/vlc)

[Rémi Denis-Courmont]

Then it's a known limitation of GL drivers that they some crash and some lock up when the window is closed abruptly. Stop the video (e.g. with S key) instead of closing the video window to side-step it.

Alternatively, force the X11 RENDER or plain X11 video outputs, but that'll increase CPU usage.

[korrode]

Meanwhile at the VLC devs meeting...

http://paradoxcomputers.com.au/stuff/vlc_mesa.jpg

[Rémi Denis-Courmont]

Har har. Veeery funny.

Historically, Xlib would abort the process when you closed the window, and VLC (and any other app) would therefore quit. Not very clean way to quit, but it worked. For some reasons, Mesa changed something and instead of aborting the process, the GL thread just locks up. I guess that's a side effect of using XCB instead of Xlib,. but that's just speculation.

If you use the VLC GUI, or another app with a GUI, the window manager will typically send a notification to close cleanly before actually closing. So then the application will shut down cleanly.

If you don't use the VLC GUI, or if you use a really crude window manager (e.g. TWM) even with another than VLC, this won't happen, and GL might freeze.

You can argue all you want. The stack traces clearly show that the lock up is within GL drivers.

[korrode]

I'm tellin' the KDE and Xfce devs you called their window managers "crude". ;-p

Seriously though, I have the issue on Xfce and one person says here they have it on KDE:
https://gitlab.freedesktop.org/mesa/mesa/issues/116

I understand where you're coming from, but surely it's worth at least opening a line of communication between the two dev teams.

Another part of the issue is that for people on LTS distros it's much easier to compile a VLC that works around Mesa's issue, or even get a fix applied/update done for VLC in the repos, than it is to do those things for a bugfixed Mesa.
I, for example, run Debian 10 (Stable), a popular and widely used distro that will not see another stable release for over a year.

[Rémi Denis-Courmont]

I never said Kwin or XFCE were crude. I do say that TWM is crude in this context.

If you think that there is lack of communication, you are welcome to go and communicate with Mesa devs. I am not going to go and ask them to fix a limitation, that they might know already and most likely don't/won't care about, and which I cannot even reproduce on my system. I use the NVIDIA driver, and it's just exiting as old Mesa drivers ostensibly did. Why would I go and disturb the Mesa devs?

[xxlsm]

It seems that the snap version does work. It uses an older version of the libva-intel-driver because on the console it says:

avcodec decoder: Using Intel i965 driver for Intel(R) Kabylake - 1.7.0 for hardware decoding

I have also tested the newest versions of the intel-media-driver, libva-intel-driver (see https://wiki.archlinux.org/index.php/Hardware_video_acceleration). With this versions this bug occurs. With the older libva-intel-driver which is included in the snap package this bug doesn't occur on my system.

I don't know if older versions of the (better) intel-media-driver will work as well.

So there indeed seems to be a correlation with the driver for hardware acceleration. However, since any other media player doesn't have this issue I would suggest to communicate with the developers of the driver since we are by far not the only users that are affected by this bug. And I would think that it is in VLCs best interest to keep its user base since such a bug is very frustrating and most inexperienced users will simply switch to another video player.

@Rémi Denis-Courmont
Maybe you can reproduce this bug by using the newer hardware acceleration drivers as well?

As a workaround I will stick to the snap version of vlc for now. Alterantively one could also use docker images but I think this is a bit overkill.

[ieleja]

btw, my system is KDE

but!

may be this "close window" event is interceptable by VLC and then VLS states that user means sending "S" and "Close Window"?

[Rémi Denis-Courmont]

There are simpler workarounds: use the VLC Qt GUI, or use the stop key (S) instead of closing the window. You don't need to use the Snap version (and in all likelihood, the Snap version will eventually break when it gets newer drivers).

[ieleja]

thanks, Rémi!

[may be it is my system somehow screwed up or me is too stupid]

if I run as my user in console

qvlc movie.mkv

VLC starts in qt mode - nice, but it also runs in my language, not english

but if I start from File Manager Dolphin - it starts in non-qt mode, I try change in preferences to qt as default, try to load additional interface and get error about second instance, and run in English

I don't know why, I think, that VLC preferences is in ~/.config/vlc

but!

thanks again for VLC and your time answering my stupid questions

for now I stay with previous workaround - use X11 output - CPU has enough power and this is main system for watching movies

BR,ieleja

[Rémi Denis-Courmont]

Using XVideo (3.0) or RENDER (4.0) output is better than X11 if that's the direction you want to take.

There's a setting in preference to disable single instance mode.

[xxlsm]

btw, my system is KDE

but!

may be this "close window" event is interceptable by VLC and then VLS states that user means sending "S" and "Close Window"?

Interesting. I also experience this bug with KDE on Arch. However, on my last system Linux Mint with Cinnamon this bug didn't occur. But I didn't know which drivers were used on that system.

There are simpler workarounds: use the VLC Qt GUI, or use the stop key (S) instead of closing the window. You don't need to use the Snap version (and in all likelihood, the Snap version will eventually break when it gets newer drivers).

Doesn't VLC use the Qt QUI per default? However, this bug also occurs when I start qvlc via the terminal which forces vlc to use the QT. The workaround to use the stop key instead of closing the video works. But it it can be still annoying when you just want to browse through a bunch of videos quickly.

[xxlsm]

Okay, now I noticed another strange think. For me it seems to be the case that this bug doesn't occur with all video files. For me this bug only occurs when i play the screen records which I recorded via OBS-Studio using the intel VA-API hardware acceleration for encoding. When I use software encoding this bug doesn't occur. For other generic video files this bug doesn't occur either. However, the snap version with the older driver isn't affected by this.

@Rémi Denis-Courmont

Do you think that this might be something? I could provide an example video file that produces the bug on my system and logs if you want.

[Rémi Denis-Courmont]

By using the GUI, I mean playing the video embedded within the GUI, as per default. The problem can only occur with non-embedded video, AFAIK. If you do get the bug with embedded video, then it is a different bug and I don't know any work-arounds in VLC.

And I personally don't care or need anything. From VLC point of view, the problem is understood: some VA and GL drivers lock up when the X connection is terminated or the window is unmapped unexpectedly.

[xxlsm]

I didn't change the default settings and I would say that the videos I play look embedded in the qt gui. I didn't even know that you are able to play the video with vlc without the gui. So you say that this is a different bug? However, the workaround of stopping the video before closing it works for me.

Should I open another thread, since you say this is a different bug?

[AllesMeins]

Just wanted to add, that I've the problem on a clean Ubuntu 20.04 install as well (with an ATI graphics card). If there is anything I can do to help to get this fixed, please let me know.

[Rémi Denis-Courmont]

With embedded or non-embedded video?