e.event_type 为up后,hold_mode函数依旧触发,导致后续语音无法识别,附带治标不治本的解决方法

[cancundeyingzi]

未大改源码,仅加了print

while task := await Cosmic.queue_in.get():

Cosmic.queue_in.put

按键

修复方法

本来想着解决依旧触发的问题..看了半天，不知道哪里出问题...为了找这个 bug，已经花了我整整三天时间....只好干脆写一个时间校验了....但是这属于治标不治本，希望有大佬能真正解决依旧触发的问题

[HaujetZhao]

你是说源码在 win 上运行良好，在 linux 上 hold mode 不正常了？

发送任务是协程，终止发送是通过取消协程任务实现的 cancel_task()

[cancundeyingzi]

根据观察,问题的直接原因是反复发送 通知结束任务 type: finish,比方说第一句话，type: finish 了两次...第二句话，开局就会读取到第一句的第二个 finish,导致第二句话开头就被掐掉.录音时间零秒

然后再观察为什么会反复发送type: finish,,发现松开按键的信号重复发送了好多次,,,,即e.ecent_type:up发送多次 对比发现，Windows 上面每句话只会发送一次按键松开信号,,,,,即e.ecent_type:up只发送一次

后面就没有继续再观察下去了，超出能力范围.....所以目前需要研究的可能是:为什么按键弹起up的信号会重复发送

在 linux 上 hold mode 不正常了？ 按键弹起信号重复发送,还无法真正确定到底是什么原因

[HaujetZhao]

推测。在 Windows 上，恢复模拟 Capslock 是发送了一个 capslock 的按下和弹起。这个动作不会触发事件监听，但是 Linux 上会触发事件监听。你把 config.py 中的 restore_key 关掉试试

[cancundeyingzi]

推测。在 Windows 上，恢复模拟 Capslock 是发送了一个 capslock 的按下和弹起。这个动作不会触发事件监听，但是 Linux 上会触发事件监听。你把 config.py 中的 restore_key 关掉试试

经过测试，确实有所好转,测试到现在没有再出现同样问题过, 不过我在大量测试中又发现一个找不到麦克风的问题,,,讲着讲着，突然从某一条消息开始就变成零秒钟....重启程序后恢复正常...不太确定是什么原因导致的，正在观察 (自动重启程序代码)

        console.print("没有找到麦克风设备", end='\n\n', style='bright_red')
        print('程序重启...')
        # 获取当前解释器路径
        p = sys.executable
        # 启动新程序(解释器路径, 当前程序)
        os.execl(p, p, *sys.argv)
        # 关闭当前程序
        sys.exit()

                console.print(f'任务标识：{task_id}')
                console.print(f'    录音时长：{duration:.2f}s')
                if duration==0:
                    stream_close(1,2)#啥参数我也不知道,反正能跑
                    print("出错尝试重启")