A new update of the Sonos plugin is now available.
You can download the ZIP file at the bottom of this page: beta3 in tags – Sonos Wireless HiFi Music Systems
Please note that the “services” subdirectory in this archive is unnecessary.
Here are the changes:
[ol][li]
Improove the way to run TTS (silence file no more required) + TTS code moved in a library
[/li]
[li]
New available engine for TTS: OSX TTS server
[/li]
[li]
New parameter Engine for the Say action
[/li]
[li]
New variable DefaultEngineTTS: default TTS engine; default value is GOOGLE; other possible value is OSX_TTS_SERVER
[/li]
[li]
New variable DefaultLanguageTTS: default language (2 characters) used by TTS; default value is “en” meaning “english”
[/li]
[li]
Changed: when calling SetURIToPlay / PlayURI with a Sonos playlist, the playlist now replaces the current queue content
[/li]
[li]
New: playback of a Sirius station with the following URI format in PlayURI command: SR:
[/li]
[li]
New: bridge is now not considered as a usual zone
[/li]
[li]
New variable CheckStateRate: delay in minutes between automatic state checks; default value is 0 meaning no automatic check
[/li]
[li]
New variable DebugLogs; default value is 0; value set to 1 enables log of additional debug information
[/li]
[li]
Changed: log of debug information
[/li]
[li]
New: better handling of Play:3 pairs
[/li]
[li]
Improove performance of XML parsing
[/li]
[li]
Improove performance when browsing content (queue content) + abort timeout in case of very big queue
[/li]
[li]
Suppress services not helpful for the final user
[/li]
[li]
Changed: new format (reduced size of the value) for the variables SavedQueues, FavoritesRadios and Queue
[/li]
[li]
Changed: files renamed for AVTransport and RenderingControl services
[/li]
[li]
Fix value for variable Title for a TuneIn radio station
[/li]
[li]
Fix escaping of XML special characters
[/li]
[li]
Variable DiscoveryResult reset at reload if set to “scanning”
[/li]
[li]
UI player tab: Truncate long items in pick lists
[/li]
[li]
UI Settings tab: display of identity for discovered Sonos changed
[/li]
[li]
UI Settings tab: current Sonos is now selected by default in the “discover” pick list
[/li]
[li]
UI Help tab: version of the plugin displayed
[/li]
[li]
UI Help tab: fixed URL for the forum
[/li][/ol]
[ol][li]
Restoring queue content (after TTS): when the queue contains items from a paying service: for a technical reason I still ignore, it looks like the required service key is notified to the Sonos official application but not to our plugin
[/li]
[li]
Restoring queue content (after TTS): it could take a lot of time if the queue content to be restored is big
[/li]
[li]
Moving TTS UI in a new tab to let the user selects the engine and setup the engine parameters
[/li]
[li]
Management of pairs
[/li][/ol]
This ordered list matches my priorities.
I would like to handle the first 3 topics before releasing the plugin on the app store.
I was fully wrong, I was just not looking at the right place (tag). What we need is provided. 8)[/quote]
It is now fixed, I hope that the fix will work with any Sonos service using the Sonos queue. As an example, it is working with Amazon Cloud Player service.
The fix is not included in the beta 3 version but is available in the “in development” version (trunk) and will of course be included in next release.
At least one reason is that I am using the action AddURIToQueue rather than the action AddMultipleURIsToQueue, that is one call for each queue item rather than one unique call.
If your queue has for example 100 items, it will produce 100 calls to AddURIToQueue that will produce 100 notifications of queue update that will produce 100 calls to browse the queue content !!! That’s clearly not optimal
Why I did it like that ? Because I don’t know how to use the action AddMultipleURIsToQueue But I will search.
For users that used a previous version of the plugin, I would recommend that you delete unused files after new installation:
- all files matching S_Sonos* in the directory /etc/cmh-ludl except S_Sonos1.xml.lzo and S_SonosGroupRenderingControl1.xml.lzo
- file Sonos_silence.mp3 in the directory /etc/cmh-ludl
- file Sonos_silence.mp3 in the directory /www/
At least one reason is that I am using the action AddURIToQueue rather than the action AddMultipleURIsToQueue, that is one call for each queue item rather than one unique call.
If your queue has for example 100 items, it will produce 100 calls to AddURIToQueue that will produce 100 notifications of queue update that will produce 100 calls to browse the queue content !!! That’s clearly not optimal
Why I did it like that ? Because I don’t know how to use the action AddMultipleURIsToQueue But I will search.[/quote]
IFor your information, I finally succeeded to use AddMultipleURIsToQueue. So the second point should be closed very soon.
For users that used a previous version of the plugin, I would recommend that you delete unused files after new installation:
- all files matching S_Sonos* in the directory /etc/cmh-ludl except S_Sonos1.xml.lzo and S_SonosGroupRenderingControl1.xml.lzo
- file Sonos_silence.mp3 in the directory /etc/cmh-ludl
- file Sonos_silence.mp3 in the directory /www/
What would happen if you did not delete them?[/quote]
Nothing bad at least for all files except S_SonosAVTransport1.xml and S_SonosRenderingControl1.xml. For these two files, if you keep them, you will be in the case that you have two services files for the same service type AVTransport:1. As the two files (S_SonosAVTransport1.xml and S_AVTransport1.xml) are identical, my assumption is that it will work well but I am not 100% sure.
I could think about a new action to check and delete all old unused service files.
I upgraded to Beta3_161 and everything is working well. The TTS now seems more responsive and returns to the previous program stream quicker. Great work!
[quote=“lolodomo, post:2, topic:179571”]There are still 4 topics requiring work:
[ol][li]
Restoring queue content (after TTS): when the queue contains items from a paying service: for a technical reason I still ignore, it looks like the required service key is notified to the Sonos official application but not to our plugin
[/li]
[li]
Restoring queue content (after TTS): it could take a lot of time if the queue content to be restored is big
[/li][/ol][/quote]
I finally found an ultra efficient way to manage queue saving and restoring, simply through a Sonos playlist (saved queue).
The change will be really noticeable. I will make more tests but I think it will be fast more or less whatever the size of the queues.
The Sonos error message “Unable to play Say.5.mp3 - the track is not encoded correctly” is back again. A reload of Vera seems to fix it, but it does seems to come back again.
You have to look at the Sonos Controller (official app) to see this error message.
The Sonos error message “Unable to play Say.5.mp3 - the track is not encoded correctly” is back again. A reload of Vera seems to fix it, but it does seems to come back again.
You have to look at the Sonos Controller (official app) to see this error message.[/quote]
Sorry, it does never happen for me.
Is there special characters in your text ? I mean, are you sure that Google produces a file not empty ?
That being said, I could add a test to check that the file is not empty before trying to play it.
[quote=“lolodomo, post:13, topic:179571”][quote=“lolodomo, post:2, topic:179571”]There are still 4 topics requiring work:
[ol][li]
Restoring queue content (after TTS): when the queue contains items from a paying service: for a technical reason I still ignore, it looks like the required service key is notified to the Sonos official application but not to our plugin
[/li]
[li]
Restoring queue content (after TTS): it could take a lot of time if the queue content to be restored is big
[/li][/ol][/quote]
I finally found an ultra efficient way to manage queue saving and restoring, simply through a Sonos playlist (saved queue).
The change will be really noticeable. I will make more tests but I think it will be fast more or less whatever the size of the queues.[/quote]
Unfortunately, it is now too much fast and it can lead to Sonos crash in particular conditions, when groups are involved and the queue is big. When a zone becomes a coordinator for a group, it apparently inherits the queue content of the previous coordinator. During this time, the queue of the old coordinator must not be updated. At least, that is my current analysis. More work and more study will be needed…
This problem could be present even in the current and previous versions, even if I never noticed it. I am not sure.
The Sonos error message “Unable to play Say.5.mp3 - the track is not encoded correctly” is back again. A reload of Vera seems to fix it, but it does seems to come back again.
You have to look at the Sonos Controller (official app) to see this error message.[/quote]
Sorry, it does never happen for me.
Is there special characters in your text ? I mean, are you sure that Google produces a file not empty ?
That being said, I could add a test to check that the file is not empty before trying to play it.[/quote]
Comment this line in the file L_SonosTTS.lua:
os.execute(DELETE_EXECUTE:format(device))
This will disable the deletion of the file.
Then, when the problem comes back, check the size of the file and try to play it from a WEB browser using this URL: http://VERA_IP/Say.XX.mp3
[quote=“lolodomo, post:16, topic:179571”][quote=“lolodomo, post:13, topic:179571”][quote=“lolodomo, post:2, topic:179571”]There are still 4 topics requiring work:
[ol][li]
Restoring queue content (after TTS): when the queue contains items from a paying service: for a technical reason I still ignore, it looks like the required service key is notified to the Sonos official application but not to our plugin
[/li]
[li]
Restoring queue content (after TTS): it could take a lot of time if the queue content to be restored is big
[/li][/ol][/quote]
I finally found an ultra efficient way to manage queue saving and restoring, simply through a Sonos playlist (saved queue).
The change will be really noticeable. I will make more tests but I think it will be fast more or less whatever the size of the queues.[/quote]
Unfortunately, it is now too much fast and it can lead to Sonos crash in particular conditions, when groups are involved and the queue is big. When a zone becomes a coordinator for a group, it apparently inherits the queue content of the previous coordinator. During this time, the queue of the old coordinator must not be updated. At least, that is my current analysis. More work and more study will be needed…
This problem could be present even in the current and previous versions, even if I never noticed it. I am not sure.[/quote]
I GOT IT 8)
There is absolutely no need to manage queues, it is done automatically by the Sonos. The only point is to manage correctly the groups, which is the case now. TTS is now fast and not dependent on your queue content. 8)
My two first remaining points are now fixed. Remains at least the third enhancement (UI for TTS), I started to change the UI but not yet finished.
Hello,
I have a Vera3, upgraded to UI6. I have a Sonos Connect that is working flawlessly.
I cannot make it work in my Vera3. I also have the UPNP event Proxy installed.
I am able to see what is playing on the Sonos, i can control play stop, volume, but some features are not working, amongst them TTS Say. Also Discover button doesn’t seem to do anything, nor ading the IP manually.
See attached pictures. I installed the Beta3 and i also checked that i have the silence.mp3.
