https://bugs.winehq.org/show_bug.cgi?id=38241 --- Comment #6 from Andrew Eikum <aeikum(a)codeweavers.com> --- Created attachment 54385 --> https://bugs.winehq.org/attachment.cgi?id=54385 winmm/tests: MCI rejects commands from threads that didn't open the device (In reply to Sagawa from comment #1)
Created attachment 51049 [details] proposed patch
From my inspection, this is MCI Mpegvideo driver, mciqtz32's issue. Generally, mci "open" and "close" can call in different threads for the same device. Therefore, the following case triggers 'CoUninitialize Mismatch' in the current implementation. 1. thread A, open foo.mp3 with MPEGVideo driver. i.e. 'open foo.mp3 alias foo type MPEGVideo'. MCIQTZ_mciOpen() silently calls CoInitialize() for thread A. 2. thread A, play foo. 3. thread B, close foo. MCIQTZ_mciClose() implicitly calls CoUnintialize() for thread B though the thread is not initialized.
Attached proposed patch introduces a task thread to avoid above situations, and DriverProc passes the arguments to the thread.
Some tests indicate this is wrong. MCI seems to reject commands from the thread that didn't open them with MCIERR_INVALID_DEVICE_NAME. See attached tests, run here: https://testbot.winehq.org/JobDetails.pl?Key=22738 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.