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

[Rémi Denis-Courmont]

If you don't believe, you can get a stack trace of the frozen VLC and see for yourself that it's Mesa that's locking up.

[charno]

I believe that the hang is in the mesa stack, and that there is a bug there.

I just think it's a bug that a feature (exiting vlc) works when accessed one way (Ctrl+q or menu), but not another way (x or Alt+F4). And that one is definitively on the vlc side.

[Rémi Denis-Courmont]

I don't know if there is or is not a bug in the VLC GUI, or in the QtGUI library that ends up triggering the Mesa bug(s). I cannot reproduce the issue so I have no ways to ascertain that.

If somebody can reproduce the problem, they're most welcome to investigate.

[gregoiregentil]

Ubuntu 20.04 with gnome and I have the same problem. Is it going to be fixed?

[100%]

̶I̶t̶ ̶l̶o̶o̶k̶s̶ ̶l̶i̶k̶e̶ ̶i̶t̶'̶s̶ ̶b̶e̶e̶n̶ ̶f̶i̶n̶a̶l̶l̶y̶ ̶f̶i̶x̶e̶d̶ ̶w̶i̶t̶h̶ ̶t̶h̶e̶ ̶l̶a̶t̶e̶s̶t̶ ̶K̶u̶b̶u̶n̶t̶u̶ ̶2̶0̶.̶0̶4̶ ̶u̶p̶d̶a̶t̶e̶s̶,̶ ̶a̶t̶ ̶l̶e̶a̶s̶t̶ ̶f̶o̶r̶ ̶m̶e̶.̶ ̶C̶a̶n̶ ̶a̶n̶y̶o̶n̶e̶ ̶c̶o̶n̶f̶i̶r̶m̶?̶

Sorry guys, it would appear I've spoken too soon, the problem still persists.

[roberthr]

I think it has something to do with desktop scaling. If I set scaling to 125% VLC hangs after quit. When I put it back to 100% it closes normaly. It happens in both KDE Plasma and Gnome on Ubuntu.

[roberthr]

Nope, it's not scaling but Xorg. With Wayland obviously closes properly.

[Rémi Denis-Courmont]

No, it's not Xorg. As noted up-thread, it's a combination of two bugs:

1) MesaGL locks up when the video window is unmapped too early (reminder link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/116 ).
2) The VLC GUI unmaps the X11 video window before GL rendering is stopped.

This bug also affects (VLC on) XWayland. Of course it won't affect pure Wayland, though there are outstanding other issues with VLC on Wayland.

[roberthr]

I think I might found the workaround. In VLC settings, go to Video and change Output from Automatic to X11 (XCB). No more hanging since then

[Rémi Denis-Courmont]

Yes but you'll ruin the performance by doing that.

[roberthr]

Well, the experience is already ruined,so performance impact does not make it much worse.

[iagreetoo]

I have the same issue with the latest Manjaro (I have to kill VLC v3.0.11.1 to be able to close it)

[Rémi Denis-Courmont]

Stop the video before you close VLC.

[roberthr]

Stop the video before you close VLC.

Does not work most of the time

[videbob]

According to mesa, this bug was fixed in version 20.2.0. I'm not so familiar with Manjaro but with Ubuntu-based distros you may need to use an external ppa to get the latest version.

https://docs.mesa3d.org/relnotes/20.2.0.html

[Tidy]

I am running Kubuntu 20.10 with MESA 20.2.1, problem still persists.

[Rémi Denis-Courmont]

Mesa rolled back the fix in latest versions, so the bug is back.

[rmdegennaro]

I think I might found the workaround. In VLC settings, go to Video and change Output from Automatic to X11 (XCB). No more hanging since then

Thank you, this worked for me; on a fully update Kubuntu 20.04 machine. Reading through the thread ruins the experience as much as the actual bug.

[hache]

Hello World!, I have the same Issue with Ubuntu 20.04 Mate with VLC v3.0.9.2 installed from "Software Boutique" (official repo) and the only way to avoid the issue was setting only one instance.

To do this just go to VLC Player : [Tools] > [Preferences] > [Interface] > check "Allow only one instance" and save.

In this way no matter if you close the VLC Player with (x) icon and get freeze in system try or background. Next time you open a media flie or a new instance of VLC this setting will force to close previous instance and open a new one so you no need to kill the old instance. I know this is just a "workaround" but I think it's better than kill the freeze instance each time you forgot to stop and close. Let's be honest, we all close without stop because this is the fast way we do in all player for last 20 years and that will not change in the user mind for next 20 years.

Hope this tip help meanwhile to wait a fix from VideoLan Dev Team. Please if it works for you, consider to share the info about OS, Desktop Environment and VLC Version to help other users.

HACHE from Argentina (sorry for my broken English but I speak Spanish!)

[linkfanel]

Hello,

We believe that one of the triggers for this bug, in particular for the part within VLC's Qt5 GUI, could be a latent issue that was revealed by some change in a newer Qt5 release. To help us investigate and diagnose this, could any reporter please share, on top of your distribution and its release version, your libQt version too? And whether the issue goes away when downgrading to older versions?

Also, can you please consider filing a bug with your distribution about it, if one doesn't exist already, mentioning it's a possible issue involving newer Qt versions? Our upstream ticket would be https://trac.videolan.org/vlc/ticket/21875 Please report to us the links to these distributions ticket.

Thanks, hopefully with your help we can sort it out.

[argumon]

Same problem here on openSUSE Tumbleweed for about half a year and I am doing regular (mostly daily) updates.
Setting 'Only one instance' does not help here, but changing Video output to X11 fixes it.

I am running Tumbleweed with KDE on X11.
Actual version is:
AME="openSUSE Tumbleweed"
# VERSION="20201123"

libQT5Core5 version is 5.15.1-5-1x86_64

I will file a bug for Tumbleweed later (if there isn't one already).

[korrode]

Will be pretty lame if there's not to be any solution to this from VLC's end and Debian 11 is released with a Mesa stack that still has this issue.

Someone suggested a possible workaround at VLC's end could be to pause the video before exiting. Is this a possibility, Rémi?

[Rémi Denis-Courmont]

There are two bugs, one in Mesa. There is another bug in either the VLC Qt plugin or in the Qt5GUI library that makes VLC destroy its window too early. Nobody cares to investigate it as it's much easier to blame the symptoms on Mesa.

I certainly don't have the Qt expertise, time and motivation to look at it myself. Patch welcome.

[tofuser]

Happy New Year everyone
I also have this bug on VLC 3.0.9.2 with Ubuntu 20.04.1 LTS.
I can add to what has already been said that the bug does not occur on all h264 videos.
If anyone is interested in reproducing the bug I can send her/him a very light 8s h264 video (158 kB) ?
If it can help I have another 8s h264 video that present no bug or I can send terminal output in debug mode (export VLC_VERBOSE=3) ?

[Rémi Denis-Courmont]

Thanks but I don't think it's really dependent on the video, just timing (and the GL drivers).