I have installed LMMS from the Win32 RC1.2 (https://github.com/tresf/lmms/releases/download/v1.2.0-RC1.2/lmms-1.1.90-win32-qt5.exe). When I start LMMS and then close it the process keeps running in the background:

The really ugly thing is that the process cannot be killed even when running Process Explorer as administrator.
The system is Windows 8.1.
I think this is a duplicate of the software crashing when exit. We've a few items tracking it, but I don't believe it to be specific to Win/Qt5.
I have same issue in Linux. I have to Ctrl+C or terminate it after I closed LMMS which I started from terminal.
I have had this issue running LMMS from the terminal in the past were it needed killed manually also, but I don't seem to have it with the latest build from git ( Built with QT5.5.1 . @karmic can you try loading a new empty project, then terminating through the GUI right away . Use all 3 methods I.e
(1) ctrl+q
(2) quit from the menu
(3) close icon on the window border.
And report back any findings thanks.
I have seen that in stable 1.1.3 and earlier.
If i recall it correctly, i gave up on ASIO after 1.0 was released, because ASIO (not lmms) caused BSOD when lmms crashed.
I believe it happens more frequently, if lmms has been idle for a while (~30 mins.
Reanimation of idle lmms is always resulting in huge cpu spikes, and lmms will 'studder' at every first note of all instruments.
(does others also see that behaviour ?
Then when its shut down, the popup tresf mentioned, will be shown, and lmms and any remoteVSTprocesses is still running in the background.
on _my_ HW / OS.
I used lmms-1.2.0-rc2 in windows 10 and I didn't encounter this. Does this still happen to you @michaelgregorius?
@Umcaruje, unfortunately I can still reproduce the problem with LMMS-1.2.0-RC2 using Windows 8.1.
When I try to kill these processes for the first time nothing happens. When I try again I get an error message (I think something like that I have no rights to do that) and the process still persists.
When I try to kill these processes for the first time nothing happens. When I try again I get an error message (I think something like that I have no rights to do that) and the process still persists.
Even running as admin ?! ..outch
RC1.1.9+ does 'this' after shotdown-crashing much less often, for me, than <=1.1.3, but it can happen, but on xp the leak-process can be killed, with no problems from TM
I got a leak-process when there was a problem with audio backend. Audio backend thread was hanging and the mixer were waiting for its FIFO buffer. If this is the reason, killing such threads might be helpful. I'm not pretty sure but I can't find any other possible reason for this.
@michaelgregorius Which audio backed did you use? Is this still there in rc4?
@PhysSong If I remember correctly I did not make any changes in the options. Here's the relevant portion of the .lmmsrc.xml:
<audioportaudio backend="MME" device="Microsoft Soundmapper - Input"/>
<audiosdl device=""/>
<mixer audiodev="SDL (Simple DirectMedia Layer)" hqaudio="0" mididev="WinMM MIDI" framesperaudiobuffer="256"/>
I am not able to reproduce the problem anymore but this might be related to changes in my hardware setup. I am now using a USB audio interface instead of an internal PCI sound card. I have tested with 1.2.0_rc2 (64 bit) and 1.2.0_rc4 (32 bit and 64 bit).
3920 seems to describe the same problem by the way. From the comment it sounds like a problem with the MIDI driver.
If so, we should be somehow reproduce that. Then we may investigate and fix that. :+1:
Please refer to my comment in #3920 for more results.
From the comment it sounds like a problem with the MIDI driver.
Did I hear MIDI? I get this crash, https://github.com/LMMS/lmms/issues/3357 (with backtrace), on Linux. I haven't seen any other pattern than perhaps it happens when there are vst pluggins in the project.
3920 seems to describe the same problem by the way.
Yes. They look like duplicates.
3920 seems to describe the same problem by the way.
Yes. They look like duplicates.
@michaelgregorius Then should we close this one?
Closing for now because #4451 fixes #3920 and there seems like no more hangs.
From my point of view also OK to close this one.
Most helpful comment
Closing for now because #4451 fixes #3920 and there seems like no more hangs.