https://bugs.kde.org/show_bug.cgi?id=421662
--- Comment #15 from Gabriel Marcano <gabemarc...@yahoo.com> ---
I've been doing some reading to understand what's going on. At least with the
libvlc audiowrapper, it does look like at some point something is causing the
AudioWrapper::stop() slot to be called, which is good. The problem is this slot
isn't what causes the inhibition management to happen-- it instead sends a stop
command to libvlc. The vlc_callback function is called, and we queue the method
that will actually update the inhibit status (audiowrapper_libvcl.cppp:360):
QMetaObject::invokeMethod(this, [this, newStatus]() {Q_EMIT
statusChanged(newStatus);}, Qt::QueuedConnection);
The problem is that this queued method might never run (and it seems to never
run) if it is queued right as the application is ending (my guess is the main
loop is no longer servicing events at that point).
--
You are receiving this mail because:
You are watching all bug changes.
