Crash after getting TTS
Closed this issue · 9 comments
Hello
Successfully installed the add-on, SIP registered and call established but then the add-on stops working and the call stays open forever.
Below are the last lines of the ha-sip log but I don't see where it goes wrong. The mp3 file plays correctly when I open it manually.
Thanks for having a look.
--end msg--
| 16:12:04.037631 [2] Call connected
| 16:12:05.048257 [2] Call is established.
| 16:12:05.048349 [ ] Calling webhook ******* with data {'event': 'call_established', 'caller': 'sip:XXX@ims.mnc001.mcc206.3gppnetwork.org;user=phone', 'parsed_caller': 'XXX', 'sip_account': 2}
| 16:12:05.061116 [ ] Webhook response 200 b''
| 16:12:05.061277 [2] Playing message: Hallo, gelieve de toegangscode in te voeren
| 16:12:05.071199 [ ] Getting audio from "https://ha-public-url/api/tts_proxy/5496cc8800bb3d5d224f9e13a00d8757b1f68b4c_nl_-_google_translate.mp3"
I guess the request for getting the audio file is failing. It looks also a bit funny with only one slash behind the https. Did you edit that manually for posting?
Yes, I edited that manually. Any ideas where to find the error message?
By the way, TTS works fine on my Google Nest Hub/Mini.
Usually a stack trace is printed after this error occurs. The problem is, that home-assistant does not keep logs after the add-on has stopped, so you need lots of luck to get that. I noticed you forked the repo, so if you run it locally you should be able to get the complete stack trace with errors.
That explains it indeed. The log is also reset after the add-on is restarted :|.
Trying to run it locally to get some more details.
I've changed the TTS error handling, so that the add-on does not crash and prints an error instead. Please try and report back!
Alright, thanks for the effort. I retried but no luck.
I updated to version 3.5.1 but this is still the last line of the log:
| 10:52:23.088981 [ ] Getting audio from "https://ha-public-url/api/tts_proxy/5496cc8800bb3d5d224f9e13a00d8757b1f68b4c_nl_-_google_translate.mp3"
Hello
It seems the add-on didn't crash but tries accessing the TTS url indefinitely. HA is only accessible on my FQDN through reverse proxy from both internal or external network and I think the add-on is blocked somewhere.
I rewrote the create_and_get_tts function and use the tts file from the /config/tts folder now and no issues anymore. This should work for all configurations I assume. Should I create a pull request for this?
Are there some official docs where you've got that info from? Are TTS files always stored in that directory? What about disabling caching? I don't want to break things for existing users.
It's indeed not the best approach because the cache folder can be changed through the config. I troubleshooted some more and it seemed the HA DNS couldn't resolve my hostname. After a DNS restart, it's working with the URL. I'm closing the issue.