Sonos plugin

[quote=“jduchon, post:579, topic:169644”]Hello,

I have the plugin working correctly for several weeks and get the same error message Hek has in my log:

luup_log:38: Sonos: error UPnP_request: status=1 statusMsg=500 result=[ Error 500

No Reason
] <0x2c689680>

Thank you all for the great work!

Jerome[/quote]

Bonjour Jérome.

I don’t have this error.
This is something for guessed, the UPnP specialist. :wink:

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:

[code]luup.call_action(“urn:micasaverde-com:serviceId:Sonos1”, “SavePlaybackContext”, {}, xxx)

luup.call_action(“urn:micasaverde-com:serviceId:Sonos1”, “RestorePlaybackContext”, {}, xxx)[/code]

Here is an update of what special URI you can use for SetURIToPlay and PlayURI callbacks in addition to the Sonos standard URI:

  • load or play a Sonos playlist by its name => use URI SQ: is the name of your playlist
  • load or play an audio input by its name => use URI AI: is the name of your audio input
  • load or play the local audio input => use URI AI:
  • load or play the local (internal) queue starting at the first track => use URI Q:
  • load or play the local (internal) queue starting at the track => use URI Q:
  • load or play a favorite radio by its name => use URI FR: is the name of the radio
  • load or play a tunein radio by its station id => use URI TR: is the a number present in the Sonos URI just before “?sid=254”

[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=“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…[/quote]

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.

AUPEO is one of the other rare free Sonos service. I will try it and investiguate what are the URI and meta data.

My code is now pushed in the trunk.

[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 ?

PS: by not working, I mean bad spelling.

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

I will test the uri with Device Spy to know if then problem is vera or sonos.

Here are the result.

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. :frowning:
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.

Fixed.

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é.