The calls work, at least in a free-standing test script (attached, with output). There are definitely special characters in the output, so you’d need to look very carefully at any parsing logic to ensure it’s “safe” when processing the responses.
It’s also possible that the call is timing out if it’s got a lot of stuff in it, since I keep the default timeouts fairly short. I ran the test scripts above directly on my Mac, so there’s also a possibility of an issue on the MiOS Lua version (but I doubt it)
2 - TTS is not working well as soon as accents are in the text. Maybe a problem of encoding (URL and/or UPnP stuff) ? Without accents, unfortunately TTS is not usable for certain language.
I've wondered if perhaps another route might work. In an alternate scheme, we "download" the Google TTS output (using [tt]os.execute("wget ...")[/tt]) and put the output [ file ] directly into the MiOS directory (like /www).
Then we tell the Sonos unit to pick it up from there using “another” path (not x-rincon-mp3radio, since it’s causing us grief in other ways…)
Using the command-line of Vera, I can run the following command:
wget --output-document bar.wav --quiet --header="Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3" \
--header="Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" \
--user-agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11" \
"http://translate.google.com/translate_tts?tl=fr&q=test%e9"
and it successfully creates a “bar.wav” file that can be retrieved from Vera using a URL like:
http://veraIP/bar.wav
To avoid concurrency headaches, across Sonos units, we could name the file something like .wav. It’s a bit kludgy, but it does appear to handle the Latin-1 characters correctly, and it’s going to present them to a Sonos unit as ASCII-7 chars (in the filename form) so we’d avoid issues there.
The potential issue is that the Sonos might “start up” prior to the file being fetched using the [backgrounded] WGET call… which would lead to us playing the last file/speech text.
There is a lot of debug code that has crept into the codebase, but this is presumably until the getAvailableServices call can be made to function. If we cannot sort that out, then we should remove it from the code prior to pushing it to apps.mios.com. As there have been drastic changes going in lately, I’ve “reset” the testing clock that I use prior to push, so that people can help stabilize it.
PS: One of the TransportState comparisons appears to be against an inline-constant that has a typo, which will need to be corrected as well. It’s in the restore call.
