Lolodomo,
Will look at a few of these over the next few days. Been a little buried @work.
As we look to release this via apps, should we obsolete the old *:device:Sonos actions, for the newer :serviceId: counterparts added a few week back, so as to avoid people getting confused by the duplicate actions (like Mute, etc)?
Might be a good time for me to clean those out since there aren’t many users…
@guessed: please merge my new changes and enhancements.
Edit: I finally succeeded to push the conde in the trunk
I don’t know why but I can’t access the SVN. My username/password is rejected.
What’s new in this version:
Favorite radios added in UI
Say callback enhanced: playback context first saved then play TTS then stop after a duration that is a new parameter set by default to 10 seconds and finally the previous playback context is restored. The duration parameter is temporary, the time we find a better solution. But the new behaviour is really cool 8)
SetURIToPlay and PlayURI callbacks enhanced to load a favorite radio by its name: use FR: as URI
SetURIToPlay and PlayURI callbacks enhanced to load a TuneIn radio by its reference: use TR: as URI; the reference is not displayed in the UI but an example is s6586
new callbacks SavePlaybackContext and RestorePlaybackContext: it allows to store the playback context at a time and restore it later. The functions behind these callbacks are used by the Say callback. Please note that the saved context is lost after a restart
TuneIn radio name displayed in the UI and the dashboard
code for XML parsing revisited
network topology now refreshed evey 5 minutes
few new variables added: AVTransportURIMetaData, CurrentService, FavoritesRadios, SonosServices
try to use the MusicService to get the available services (function getAvailableServices): the not working code is commented.
For radios (favorite and tunein), I am curious to know if it is working for everybody as I am using a hardcoded desc SA_RINCON65031_ and I am not certain that:
it is the same for everybody
it is the same for all radios
What would remain to do regarding tunein radio would be to retrieve the logo of the radio to display it inside the Vera device.
For the Say callback, I know that it is not what you expected guessed, but please take it as it is, the time we find a better solution. By the way, that is at least a mean to test my context save/restore feature.
Talking about the context saving/restoring, it could work for every service but I need feedback. Of course, I tested it with success for tunein radios. To test it, either use the Say feature or use these lines of code in a scene:
[quote=“guessed, post:582, topic:169644”]Lolodomo,
Will look at a few of these over the next few days. Been a little buried @work.
As we look to release this via apps, should we obsolete the old *:device:Sonos actions, for the newer :serviceId: counterparts added a few week back, so as to avoid people getting confused by the duplicate actions (like Mute, etc)?
Might be a good time for me to clean those out since there aren’t many users…[/quote]
Mute, UnMute and SetVolume can probably be deleted.
SetFileToPlay has not a real interest as covered by SetURIToPlay. I could even add a control in SetURIToPlay to consider that the parameter is a file if it starts with a / ?
SetURIToPlay and PlayURI could certainly be merged in one unique callback with a parameter requesting to only load the URI or to load and play it. By the way, I don’t imagine in which cases users want to load something without playing it…
[quote=“lolodomo, post:588, topic:169644”]Before releasing, I would like:
you help me to make the function getAvailableServices working with the call to MusicServices.ListAvailableServices()
I would like to display in the UI the Sonos service in use, something like “TuneIn (s6586)”. That would help users to use the “TR:xxxxx” URI in scene.[/quote]
@guessed; I just committed the change for the second point. So, as soon as the first point is solved, that’s ok for me.
Ok, I have done my tests and they are positive after few little changes (committed in the trunk).
I can confirm that playback context save/restore is working for this service too (and should work for every service I suppose), meaning the AUPEO radio is restarted after TTS. The playlist is new, I think it is normal, it is the behaviour when you stop and then play one AUPEO radio.
Album art for AUPEO radio is now working too 8) Unfortunately, I still don’t know where to get the tunein radio logo.
The only thing I have to change in the UI concerns the title. For a service like AUPEO, you have the title of the radio and the title of the track. So I have to manage two different information in the UI.
People using other services (Pandora, Deezer, Spotify, …) are welcome to give feedback.
Yes, resume after TTS worked really good. Thanks lolodomo!
Had a little problem with swedish characters (åäöÅÄÖ) though… Strange… did some extra logging and all looked fine and the string is encoded before it gets sent to StartAutoplay.
Could it be that it gets double encoded somewhere after Say-function?
[quote=“hek, post:593, topic:169644”]Yes, resume after TTS worked really good. Thanks lolodomo!
Had a little problem with swedish characters (åäöÅÄÖ) though… Strange… did some extra logging and all looked fine and the string is encoded before it gets sent to StartAutoplay.
Could it be that it gets double encoded somewhere after Say-function?[/quote]
Yes, same problem with french characters (éàè…).
The google URL generated is working when entered in a web browser but not when passed to Sonos.
It could be that the Vera is modifying these characters in the URL ?
Yes… maybe… but but why would vera mess up parameters? Or is the Sonos involved in modifying the url?
Here in another url-encoder… but I don’t thing it would make much difference.
local function urlEncode (s)
if (s ~= nil) then
s = s:gsub("\n", "\r\n")
s = s:gsub("([^%w ])", function (c)
return string.format("%%%02X", string.byte(c))
end)
s = s:gsub(" ", "%%20")
end
return (s or "nil")
end
First try: test
The generated URI is x-rincon-mp3radio://translate.google.com/translate_tts?tl=fr&q=test
=> works fine in Sonos when called from Device Spy
=> works fine in Sonos when called from Vera (plugin)
=> //translate.google.com/translate_tts?tl=fr&q=test works fine in a web browser
Second try: testé
The generated URI is x-rincon-mp3radio://translate.google.com/translate_tts?tl=fr&q=test%c3%a9
=> é not correctly said in Sonos when called from Device Spy
=> é not correctly said in Sonos when called from Vera (plugin)
=> //translate.google.com/translate_tts?tl=fr&q=testé works fine in a web browser
After a short search, I discovered that %c3%a9 is é coded in UTF-8.
Then I tried with é coded as %e9 with this URI: x-rincon-mp3radio://translate.google.com/translate_tts?tl=fr&q=test%e9
=> é not correctly said in Sonos when called from Device Spy
=> //translate.google.com/translate_tts?tl=fr&q=test� works fine in a web browser
My conclusion would be that the problem is Sonos not supporting these special characters in URI.
Nothing to do with Vera or plugin.
To continue on the same subject, I tried to load a MP3 file name containing a é (%c3%a9): A l’ombre de l’été.mp3
x-file-cifs://FREEBOX/Disque%20dur/Musiques/A%20l’ombre%20de%20l’%c3%a9t%c3%a9.mp3
And it works well!
So we cannot say it exists a general problem with accents in Sonos URI. I don’t understand why it does not work with the google URI.
Talking about that, I discovered another problem relative to the plugin. As XML is used, some characters are XML escaped. For example ’ becomes ' in result from UPnP requests. So we have to replace ' by ’ when using the returned data as an URL. It is the reason why one of my album art is not displayed by the plugin.
Regarding the tunein radio logo, searching on the tunein web site, I discovered that raidoo logo are here with two different sizes:
In this example, s75560 is the “reference” of the tunein radio.
Amazon CloudFront est donc utilisé.