[quote=“hek, post:639, topic:169644”]Ok, the following code generates an test.wav reachable on
/test.wav
os.execute("wget --output-document /www/test.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="..language..
"&q="..url.escape(defaultValue(lul_settings, "Text", "The quick brown fox jumps over the lazy dog"))..
"\"")
But how do I make the sonos play it?
Tried modifying say like this(with my vera ip hardcoded). But it didn’t work. Which protocol should I use?
Google produces a MP3 file, not a WAV file. You can see it putting the translate URL in a web browser. The file is named translate_tts.mp3.
Then I suppose that such an URI should work with Sonos: x-rincon-mp3radio:http://192.168.178.100/test.mp3
Maybe without the http.
I think we don’t need charset ISO-8859-1 as Google traduction seems to work well with UTF-8 and by the way, url.escape seems to produce an UTF-8 encoded string.
Finally, is os.execute("wget … returning only when the file is downloaded ?
That’s odd. My test program didn’t have it defined, and it worked just fine.
I’ll run my test program directly on Vera tonight and see how it behaves…
[quote=“lolodomo, post:638, topic:169644”]I finally found where was the problem with MusicServices.ListAvailableServices.
In SONOS_MUSICSERVICES, you forgot to define event. And it seems to be important…[/quote]
Apart from experiments, I wouldn’t use [tt]os.execute()[/tt] unless there’s a background operator in there. Either that, or the original [tt]popen()[/tt] suggestion that @hek made earlier.
If [tt]popen [/tt]is used, then we need to remove the -q option, and only “wait” until the first byte is returned before telling the Sonos to start “saying”… hopefully to introduce some parallelism into this, since the [tt]Say[/tt] command will take some time to fire up anyhow.
Otherwise we’ll be locked in to however long it takes to produce-and-download the content from the TTS provider.
PS: Google “checks” the inbound TTS URL, and 403’s a normal [tt]wget[/tt], which is why I added all the header options. These were simply cloned from what my browser was providing (for better or worse)
[quote=“lolodomo, post:641, topic:169644”]Google produces a MP3 file, not a WAV file. You can see it putting the translate URL in a web browser. The file is named translate_tts.mp3.
Then I suppose that such an URI should work with Sonos: x-rincon-mp3radio:http://192.168.178.100/test.mp3
Maybe without the http.
I think we don’t need charset ISO-8859-1 as Google traduction seems to work well with UTF-8 and by the way, url.escape seems to produce an UTF-8 encoded string.
Finally, is os.execute("wget … returning only when the file is downloaded ?[/quote]
It worked! My sonos speaks swedish!
Yeah mabe we can remove the accept ISO…
os.execute seems to wait… But it is hard to say because it is really fast.
Must stop announce stuff in our speakers for the evening now. My wife is complaining
os.execute("wget --output-document /www/test.mp3 --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="..language..
"&q="..url.escape(defaultValue(lul_settings, "Text", "The quick brown fox jumps over the lazy dog"))..
"\"")
AVTransport.StartAutoplay(
{InstanceID=instanceId,
ProgramURI="x-rincon-mp3radio://192.168.178.100/test.mp3",
ProgramMetaData="",
Volume=volume,
IncludeLinkedZones=1,
ResetVolumeAfter=1})
local ip = "192.168.1.20"
os.execute(string.format("wget --output-document /www/Say.%s.mp3 --quiet "..
" --header \"Accept-Charset: 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=%s&q=%s\"",
ip, language, url.escape(defaultValue(lul_settings, "Text", "The quick brown fox jumps over the lazy dog"))))
local url = string.format("x-rincon-mp3radio://%s/Say.%s.mp3", ip, ip)
Without ISO-8859-1. I don’t know how to get the IP of the Vera…
It seems that os.execute returns immediately.
Another good thing is that we have not what guessed feared, meaning risk of reading the old file. I always get the new one, it might be because we then use a stream URI.
Maybe we could trigger this way of say in a setting (variable) ?
Or maybe we could check if the text contains special characters. If it does, we use the os.execute. If not, we use the old way to do it ?
I commit nothing now. By the way, we need a way to get the IP of the Vera.
I’m happy, the 2 remaining bugs are now fixed (or at least we know how to fix them).
PS: remains the Browse with “AI:”. @guessed: is it at least working for one of your Sonos unit (Play:5) ?
… plus - at least on my platform, VeraLite and play:3 - an issue with the display of radio station icons : I only get a flashing frame without any content.
@lolodomo,
I get the same error on both my Sonos Connect, and my Sonos Play5. I’ve pasted a full version of it below, but basically we’ll see a HTTP-500 error when there’s a SOAP-Fault.
The details of the payload will be the actual SOAP-Fault as reported by the device (also in XML). Often, as is the case with this one, they’re just a generic “Vendor error” type of response.
A while back I noticed that some of the SOAP calls were sensitive to the current-state of the device. Things like whether it’s playing content, and whether it was radio or CIFS-based, would impact certain [status] calls. In the cases here, I’m running them against Sonos devices that aren’t otherwise doing anything (they’re effectively idle).
It’s possible that these calls are erroring out because of a common state that a few others here and I are sharing, and something that you’re not. Unfortunately, my system is in a mess since I migrated to a new Mac, so I can’t test the file-sharing stuff, just the TuneIn stuff.
I’ve broken the log lines up for readability in the forum.
Oops. I just ran it up in Firefox/Firebug and I see the same flickering behavior. In fact, for something like the Radio station “ABC Triple J” (Australia), we’re making the following URL/image call from Firefox: http://d1i6vahw24eb07.cloudfront.net/s99476q.png
and this is returning a HTTP-403 error with a response body like the following:
[quote=“guessed, post:654, topic:169644”]@lolodomo,
I get the same error on both my Sonos Connect, and my Sonos Play5. I’ve pasted a full version of it below, but basically we’ll see a HTTP-500 error when there’s a SOAP-Fault.
The details of the payload will be the actual SOAP-Fault as reported by the device (also in XML). Often, as is the case with this one, they’re just a generic “Vendor error” type of response.
A while back I noticed that some of the SOAP calls were sensitive to the current-state of the device. Things like whether it’s playing content, and whether it was radio or CIFS-based, would impact certain [status] calls. In the cases here, I’m running them against Sonos devices that aren’t otherwise doing anything (they’re effectively idle).
It’s possible that these calls are erroring out because of a common state that a few others here and I are sharing, and something that you’re not. Unfortunately, my system is in a mess since I migrated to a new Mac, so I can’t test the file-sharing stuff, just the TuneIn stuff.[/quote]
Maybe it happens as soon as you have more than one Sonos ?
By the way, I can forget the browse “AI:” and use the network topology to produce one line input for each Sonos unit. But that means one entry will be generated for the Play:3 too.
The change is relatively easy to do. I will do it this evening.
Later, when I will own a second Sonos, I will more investiguations regarding Browse function. I am almost certain that Sonos control applications are using Browse to list the line-in.
[quote=“guessed, post:655, topic:169644”]Oops. I just ran it up in Firefox/Firebug and I see the same flickering behavior. In fact, for something like the Radio station “ABC Triple J” (Australia), we’re making the following URL/image call from Firefox: http://d1i6vahw24eb07.cloudfront.net/s99476q.png[/quote]
Could you find this radio on the tunein web site and provide the link ?
To doing a search with ABC triple J, I find severak one but with a different sXXXXX.
The “no icon” issue happens with all my (favorites) stations : France Inter, FIP, RMC… It’s with TuneIn service.
I use the latest Firefox browser on MacOS.
![http://d1i6vahw24eb07.cloudfront.net/s99476q.png[/quote]](http://d1i6vahw24eb07.cloudfront.net/s99476q.png%5B/quote%5D){kind=link}