78
Speaking 状态下 接收服务器回传数据异常时无法离开 speaking 状态
Answers checklist.
- [x] I have read the documentation XiaoZhi AI Programming Guide and the issue is not addressed there.
- [x] I have updated my firmware to the latest version and checked that the issue is present there.
- [x] I have searched the issue tracker for a similar issue and not found a similar issue.
XiaoZhi AI firmware version.
v1.4.6
Operating System used.
Linux
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Power Supply used.
USB
What is the expected behavior?
在 speaking 状态下触发 Application::ToggleChatState() 或 Application::AbortSpeaking(AbortReason)，对话应当立刻切换至 listening 状态。
What is the actual behavior?
listening 状态结束、进入 speaking 状态时，设备可能出现以下两种情况
- 不打印
Application: << 回传文字内容log - 打印
Application: << 回传文字内容log，但没有音频播放
此时，设备卡在 speaking 状态，无法自动恢复正常；手动触发 Application::AbortSpeaking(AbortReason) 无法离开 speaking 状态，只能通过重启/reset恢复。
Steps to reproduce.
普通对话时可能触发
WebSocket 协议时复现概率更大
Debug Logs.
I (75719) Application: STATE: listening
I (80507) Application: >> 给我说个笑话吧
I (80529) Application: STATE: speaking
[触发 Application::AbortSpeaking(kAbortReasonNone)]
I (93183) Application: Abort speaking
[触发 Application::AbortSpeaking(kAbortReasonNone)]
I (97442) Application: Abort speaking
[触发 Application::AbortSpeaking(kAbortReasonNone)]
I (101643) Application: Abort speaking
More Information.
No response
偶尔发生的吗？看起来是服务器没有返回tts.stop
我也发现了，概率蛮大,日志看也是服务器没有返回tts.stop，是否跟网络不稳定有关？
Wi-Fi还是4G版本呢？
偶尔发生的吗？看起来是服务器没有返回tts.stop
我也发现了，概率蛮大,日志看也是服务器没有返回tts.stop，是否跟网络不稳定有关？
Wi-Fi还是4G版本呢？
WiFi
偶尔发生的吗？看起来是服务器没有返回tts.stop
我也发现了，概率蛮大,日志看也是服务器没有返回tts.stop，是否跟网络不稳定有关？
Wi-Fi还是4G版本呢？
经常发生在按键调用ToggleChatState打断对话之后
偶尔发生的吗？看起来是服务器没有返回tts.stop
我也发现了，概率蛮大,日志看也是服务器没有返回tts.stop，是否跟网络不稳定有关？
Wi-Fi还是4G版本呢？
经常发生在按键调用ToggleChatState打断对话之后
有可能是最近更新的版本的bug，不过还需要研究如何快速重现。
偶尔发生的吗？看起来是服务器没有返回tts.stop
我也发现了，概率蛮大,日志看也是服务器没有返回tts.stop，是否跟网络不稳定有关？
Wi-Fi还是4G版本呢？
我的4G版本，最近新版本也会出现这种情况，只能rst重启，感觉是服务器接口压力上来了？
偶尔发生的吗？看起来是服务器没有返回tts.stop
我也发现了，概率蛮大,日志看也是服务器没有返回tts.stop，是否跟网络不稳定有关？
Wi-Fi还是4G版本呢？
我的4G版本，最近新版本也会出现这种情况，只能rst重启，感觉是服务器接口压力上来了？
设备IP是国内的吗？最近在升级海外加速线路，不知道跟这个有没有关系。
偶尔发生的吗？看起来是服务器没有返回tts.stop
我也发现了，概率蛮大,日志看也是服务器没有返回tts.stop，是否跟网络不稳定有关？
Wi-Fi还是4G版本呢？
我的4G版本，最近新版本也会出现这种情况，只能rst重启，感觉是服务器接口压力上来了？
设备IP是国内的吗？最近在升级海外加速线路，不知道跟这个有没有关系。
我的是国内
偶尔发生的吗？
频率不算低，每天日常使用时可以触发
不过还需要研究如何快速重现
正常对话，某次进 speaking 后没有声音播放基本可以重现
可以考虑在本地加一个多次打断（但未收到 tts.stop ）时强行进入 Idle 的逻辑？
偶尔发生的吗？看起来是服务器没有返回tts.stop
我也发现了，概率蛮大,日志看也是服务器没有返回tts.stop，是否跟网络不稳定有关？
Wi-Fi还是4G版本呢？
我的4G版本，最近新版本也会出现这种情况，只能rst重启，感觉是服务器接口压力上来了？
设备IP是国内的吗？最近在升级海外加速线路，不知道跟这个有没有关系。
国内4G物联网