pygrabber与bleak库共存时出现Windows GUI线程回调错误的解决咨询

这个问题的核心是Windows COM线程模型冲突：pygrabber依赖DirectShow（基于Windows COM技术），导入或初始化它时会把线程设置为单线程公寓（STA）模式；而bleak在Windows上扫描蓝牙设备时，其底层实现需要多线程公寓（MTA）模式的线程环境。当子进程继承了主进程的STA设置后，bleak的回调机制就会失效，触发你看到的错误。

下面给你几个针对性的解决方案，按推荐程度排序：

方案1：将pygrabber的导入和使用限制在主进程（最推荐） #

Windows下multiprocessing的spawn模式会让子进程重新执行整个脚本——如果你在模块级别导入pygrabber，子进程也会跟着加载它，导致线程环境被修改。只需把pygrabber的导入移到if __name__ == '__main__'代码块内，让子进程完全不加载pygrabber，就能彻底隔离两者的线程环境：

修改后的完整代码：

# -*- coding: utf-8 -*-

import multiprocessing 
import asyncio
from bleak import BleakScanner

# 移除模块级别的pygrabber导入，只在主进程按需导入


async def bluetooth_receiver_start():
    print("bluetooth_receiver_start")

    try:
        devices = await BleakScanner.discover()
        print("scanned devices:")
        for device in devices:
            print(f"  - {device.name} ({device.address})")

    except Exception as e:
        print(f"device search error: {e}")
        return

def bluetooth_process():
    print("bluetooth_process started")
    asyncio.run(bluetooth_receiver_start())
    print("bluetooth_process finished")

if __name__ == '__main__':
    # 仅在主进程中导入并使用pygrabber
    from pygrabber.dshow_graph import FilterGraph
    
    process_bluetooth = multiprocessing.Process(target=bluetooth_process)
    process_bluetooth.start()

    try:
        devices = FilterGraph().get_input_devices()
        for device_index, device_name in enumerate(devices):
            print(device_name)
    except Exception as e:
        print(f"pygrabber error: {e}")

方案2：在蓝牙子进程中重新初始化COM线程模型 #

如果你因为某些原因必须在模块级别保留pygrabber的导入，可以在蓝牙子进程中手动将COM线程模型切换回MTA，覆盖继承的STA设置。需要先安装pywin32库：pip install pywin32，然后修改蓝牙进程的逻辑：

def bluetooth_process():
    print("bluetooth_process started")
    # 重新初始化COM为多线程公寓模式，适配bleak的需求
    import pythoncom
    pythoncom.CoInitializeEx(pythoncom.COINIT_MULTITHREADED)
    
    try:
        asyncio.run(bluetooth_receiver_start())
    finally:
        # 确保释放COM资源
        pythoncom.CoUninitialize()
    
    print("bluetooth_process finished")

方案3：将pygrabber操作也放入独立子进程 #

如果后续你需要扩展功能，比如在主进程之外使用pygrabber，可以把它的设备查询逻辑也封装到单独的子进程中，让两个功能完全在隔离的进程空间运行，彻底避免线程模型互相影响：

# 新增pygrabber的进程函数
def pygrabber_process():
    try:
        from pygrabber.dshow_graph import FilterGraph
        devices = FilterGraph().get_input_devices()
        for device_index, device_name in enumerate(devices):
            print(device_name)
    except Exception as e:
        print(f"pygrabber error: {e}")

if __name__ == '__main__':
    process_bluetooth = multiprocessing.Process(target=bluetooth_process)
    process_pygrabber = multiprocessing.Process(target=pygrabber_process)
    
    process_bluetooth.start()
    process_pygrabber.start()
    
    # 等待两个进程完成
    process_bluetooth.join()
    process_pygrabber.join()

总结 #

• 方案1最简洁，完美匹配你当前的需求（主进程用pygrabber，子进程用bleak）；
• 方案2适合必须保留模块级导入的特殊场景；
• 方案3适合后续功能扩展的复杂场景。

备注：内容来源于stack exchange，提问作者taichi