I’ve got two picroft installations and one mark 1. All of them are running from the stable release. I don’t kn ow precisely what triggered the problem but seemingly at random, one or more of them will stop speaking. They continue to respond to commands however (which I can determine through my openhab skill and telling the mute devices to turn on and off the lights). At points in the past, I had some of them speaking and others mute but now all three of them are silent. I have been using the google TTS and I believe I have managed to correct a device by simply toggling between mimic and google and then updating config on the troublesome device, but that doesn’t seem to be working for me currently. It’s definitely not a volume problem as I can use affected devices to play music on spotify and can hear the tones when I speak the wake word. I just never get any TTS from the devices. Is there a trick to getting mycroft to speak again once it’s started giving me the silent treatment?
google tts actually uses the google translate TTS (the one in the actual google.translate webpage) , so it is rate limited if you use it too much
use another TTS engine and it should start speaking, if it doesnt then you got a different problem
Yeah, I’m in that latter camp - that is, changing the TTS provider does not recover my devices’ ability to speak.
Thanks for reporting this @bucketman, and sorry to hear you’re experiencing these issues.
We don’t currently have any Known Errors on file for Google TTS or Mimic TTS, so I’m wondering if this might be say a Device-not-starting-the audio service properly on boot. Have you had any recent power outages where you are? Could the Devices have rebooted recently?
The first thing I’d like to do is check your web_config_cache.json file if you wouldn’t mind providing it?
I’d also try restarting the audio service on each of the Devices:
pi@mark_1:~ $ sudo service mycroft-audio stop
pi@mark_1:~ $ sudo service mycroft-audio start
pi@mark_1:~ $ sudo service mycroft-speech-client stop
pi@mark_1:~ $ sudo service mycroft-speech-client start
Well, you’re certainly on to something there @KathyReid:) On my mark 1, I just did the audio and speech system restarts and that device is working now. So I ssh’ed to another affected device and here’s the json file you asked after:
pi@picroft:~ $ cat /opt/mycroft/web_config_cache.json
{“date_format”: “MDY”, “tts”: {“espeak”: {“created_at”: 1517781842587, “updated_at”:
1526336994763}, “module”: “google”, “marytts”: {“created_at”: 1517781842585, “updated_at”:
1526336994761}, “mimic”: {“created_at”: 1517781842589, “voice”: “ap”, “updated_at”:
1526336994765}, “google”: {“created_at”: 1517781842588, “updated_at”: 1526336994757},
“fatts”: {“created_at”: 1517781842586, “updated_at”: 1526336994759}}, “opt_in”: false,
“created_at”: 1517781842572, “updated_at”: 1526336994737, “listener”: {“energy_ratio”: 1.5,
“created_at”: 1517781842591, “updated_at”: 1526336994978, “channels”: 1, “sample_rate”:
16000, “multiplier”: 1.0, “threshold”: 1e-90, “phonemes”: “HH EY . M AY K R AO F T”,
“wake_word”: “hey mycroft”}, “time_format”: “half”, “skills”: {“directory”: “~/.mycroft/skills”,
“created_at”: 1517781842590, “updated_at”: 1526336994976, “stop_threshold”: 2.0}, “stt”:
{“google”: {“created_at”: 1517781842578, “updated_at”: 1526336994746}, “ibm”:
{“created_at”: 1517781842580, “updated_at”: 1526336994743}, “mycroft”: {“created_at”:
1517781842575, “updated_at”: 1526336994739}, “module”: “mycroft”, “wit”: {“created_at”:
1517781842573, “updated_at”: 1526336994754}, “openstt”: {“created_at”: 1517781842583,
“updated_at”: 1526336994750}}, “location”: {“coordinate”: {“latitude”: 45.308819, “created_at”:
1491885602083, “updated_at”: 1491885602083, “longitude”: -75.898684}, “city”:
{“created_at”: 1491885601986, “state”: {“country”: {“created_at”: 1486117561146, “code”:
“CA”, “name”: “Canada”, “updated_at”: 1486117561146}, “created_at”: 1486117561095,
“code”: “ON”, “name”: “Ontario”, “updated_at”: 1486117561095}, “code”: “Ottawa”, “name”:
“Ottawa”, “updated_at”: 1491885601986}, “created_at”: 1491885601982, “updated_at”:
1491885601982, “timezone”: {“code”: “America/Toronto”, “name”: “Eastern Standard Time”,
“dst_offset”: 3600000, “created_at”: 1486117561337, “updated_at”: 1486117561337, “offset”:
-18000000}}, “enclosure”: {“created_at”: 1517781842592, “rate”: 9600,
Note that the file just ends there - like it looks like it’s been truncated - concurrency bug or unexpected power loss when writing out the file, perhaps?
Anyway, now when I issue those command to restart audio and speech on this new device, it also is recovered.
We did have a series of power failures during a storm recently. But it seems to me that the software should be robust against this kind of problem. Would you like me to open a bug report for this?
Thanks a ton for your help!
Awesome to hear it’s working @bucketman, the Linux command line sorcery has done the trick 
Totally agree it should be a bit more resilient. I have a suspicion, not proven, that the issue is due to power fluctuations to the Device. I’m in Australia on 240 V, 50 Hz power, and I use an adaptor because I have an American power adaptor for the Mark 1s I have here. The adaptors aren’t a great physical fit and sometimes I knock them because I’m a klutz. So Mark 1 reboots, sort of, but doesn’t come back properly, because it’s more like a power interruption than a true reboot. That’s my observation anyway.
Not sure how to improve it other than to say run it through some sort of surge protector?
That web_config_cache.json definitely looks like a truncate-during-write - which would happen if power was cut unexpectedly.
The only suggestion I’d have other than ensuring the underlying FS is resilient to power loss would be to minimize the window over which the issue can occur. A way to do that would be to write any files to a temporary filepath and then rename the file to its proper name. That way, unless the power loss came during the rename, you either have the entire old file being used or the new one but never a portion of either. I also suspect that the worst that would happen should the power loss occur during the rename would be that the file would end up not present at all - but that should be a simpler problem to handle programmatically than is handling a malformed one.