restore state after say / sayAll

[gbrehmer]

It would be very nice, when the music will continue to play after the announcement. As a alternative it should be possible to restart music with the play/pause- button / http-call. Currently only the say-command is repeated after pressing the button. Skipping the TTS-Track is also not possible. In addition with sayAll it happens that the playlist after the merge and split is not the same like before the say-command. One playlist wins and is copied to all devices.

[julesbike]

+1 for me. Yes ideally it would return to the last playlist...I guess this would be hard as I can't imagine that Sonos will be able to hold this in memory.

There are a couple of possible workarounds... What about just putting the announcement next in the queue and jumping straight to next song. This would not work with Radio but should be ok with regular playlists.

I've not tested this but could you feed the announcement through line-in or does this kill the playlist too?

[jishi]

Restoring to the queue is actually not a big issue. They players can either play from the queue, or stream from radio / url etc without touching the queue. It will remain and it will say "Not in use" on the official controller.

Just keeping trackno and elapsed time and restore it after the say command has finished is already done in the sayall command (although with unreliable result), and this can be replicated here as well. If the player was grouped before the say command, it should restore itself properly, but as explained in the readme this works with unexpected behavior if the player that gets the command is coordinator (in charge of playback).

Injecting the say command into the queue, would be an option, but I don't think it's a good one. It will remain there when rewinding the queue, and you probably want the TTS to play as soon as possible.

[ppitkin]

Hi, firstly great tool. I appear to be having a bit of an issue with the say and sayall commands... When I use "say" it takes my device out of any group it may be in, stops playing the current radio stream (I only use radio stream by the way and not queues), plays the voice track and then stops. It doesn't seem to put the device back into the state it was previously. Taking a quick look at the code it appears it should put it back to the previous state i.e. back into the group and then start replaying the radio stream.

On using "sayall" it appears to group all my devices and then play the voice track. However I never get to hear anything. The volume on the group has been set to 50%. The voice track appears to have been loaded. I quess there is some sort of timing issue. Again the devices are not returned to their previous states. They remain in the group. What is also a bit strange is that when I manually take the group apart it suddenly starts to regroup things again in a seemingly random manner. (I'm monitoring this using the standard Sonos application for windows).

OK a bit more information on the sayall behaviour. 1) I have 5 sonos devices. No groups defined. 1 device playing a radio stream 2) I have the web browser send the command "http://192.168.0.30:5005/sayall/Placing%20the%20Chalet%20into%20Away%20Mode" 3) In the sonos GUI i see the devices get groupped and the volume adjusted and the voice file gets assigned. I hear NO sound! 4) I click the play button on the GUI and I hear the voice say the desired text. 5) after playing the text it starts to un-group some of the devices but then starts grouping some of them again. What I was left with at the end was one device on its own and the other 4 devices in a group. both the group and the single device were showing that the voice file was assigned to it. Also strangely when I play the file again on the group (in the sonos GUI) it only plays on 1 device. The grouping does not change again once the file is replayed a second time.

Let me know what other imformation you would need to help you investigate/debug this issue

[infofiend]

Great work!

Sayall command will do the following:

IF my speakers (3) are grouped: All speakers will UNgroup, place the desired text into the queue, but only one speaker will say the desired text. Strangely, it doesn't matter which speaker is currently the master speaker of the group -- the same speaker will be used to say the desired text. After one speaker says the text, Sonos will group the non-master (2) speakers back into a group, but the master speaker is not grouped.

IF ungrouped, all speakers will group and place the desired text into the queue, but only one speaker will say the desired text. Strangely, it doesn't matter which speaker is currently the master speaker of the group -- the same speaker will be used to say the desired text.

Volume - The volume is changed for each speaker - but not to 50% rather than to 20% level. Then volume returns to pre-sayall levels for each speaker.

Resume - None of the speakers resume playing the music in the queue, regardless of grouped / ungrouped

I attach 3 screenshots of what appears in the Terminal when I send the sayall request:

[ppitkin]

Hi, any chance of you taking a look at why the say and SayAll functions are not restoring the state after playing the text message? This is one of the most usefull features of your API and it would be great if these small issues could be ironed out. From what I can see, when I use a simple say command to 1 sonos speaker that is not in any group, then it plays oK but simply does no restore of the previous state. This is confirmed if you issue a "state" command before and after the say call.

BTW I'm not getting anything like the messages that the previous poster is seeing in the console. I have also seen that If I am playing an MP3 track and then switch to a radio station and issue a "state" command some of the elements returned relate to the mp3 file that was previously being played. It may be that some elements are not relevant for a radio station but surely in this case they should be blanked out and not contain historical values.

[jishi]

Hi, to follow up on the questions raised here and in #56:

I have had very little time left over in the last year to work on this. Hopefully I will have some time in late June and a couple of months since I will be in between jobs and might become a bit bored on my vacation.

Regarding the restoration, since the sayAll still suffers from some issues, these needs to be resolved before it will be fully functional, even for the say command. I have a few ideas on whats wrong, primarily for the radio feeds. The URI that is storeas as AVTransport doesn't not correlate with the actual URI that it wants when restoring the state (the transport URI is set to the actual http URL for the stream), but is part of the radio metadata (an x-sonos-stream: uri), so this needs to be considered when storing the previous state somehow. Invoking that uri instead, triggers the appropriate meta data fetch and radios should resume correctly.

[westside11]

Thanks jishi - Definitely interested in this as well. Seems to affect all my Google Play Playlists and network playlists files. Let me know if you need any help troubleshooting (when you get to it) - I'm running on Git shell in Windows 8 and going to try Win Server 2003 this coming weekend. Really appreciate this - love the tool.

[ppitkin]

Likewise. Many thanks.

It would be good to get this working and appreciate that you have a “day job” as well. If I can help in any way with testing then please let me know.

BTW I was also thinking about trying to integrate your API into the new “node” concept that universal-devices are introducing with Version 5 of their ISY-994 home automation controller. So if it’s possible to get it fairly stable that would be great.

I almost solely use my Sonos systems for playing internet radio streams – although I do have an album library of more than 6,000 albums I just can’t be bothered to search for things or build playlists. Selecting a radio station with the theme I’m interested in is just much easier (especially when its stored on the “favourites”). I guess I’m using it a bit differently to most people as getting the radio stations automated is always the bit people seem to leave to the end J.

From: westside11 [mailto:notifications@github.com] Sent: Monday, June 01, 2015 16:51 To: jishi/node-sonos-http-api Cc: ppitkin Subject: Re: [node-sonos-http-api] restore state after say / sayAll (#34)

Thanks jishi - Definitely interested in this as well. Seems to affect all my Google Play Playlists and network playlists files. Let me know if you need any help troubleshooting (when you get to it) - I'm running on Git shell in Windows 8 and going to try Win Server 2003 this coming weekend. Really appreciate this - love the tool.

— Reply to this email directly or view it on GitHub https://github.com/jishi/node-sonos-http-api/issues/34#issuecomment-107546348 . https://github.com/notifications/beacon/AKyrHOMgdYVSKt5q75bCujbOG_QcV_Jmks5oPGjkgaJpZM4DWeBr.gif

[westside11]

ppitkin - I'm also using calling this node with an ISY994 - so happy to contribute with that regard as well.

[ppitkin]

Hi Jimmy,

I’ve been doing a bit more testing trying to see if I could spot where the error is.

First of all I can say 100% that it is not related to radio stations alone. The problems occurs on my system regards of if I have an mp3 file playing from the queue or if a radio station is playing.

First of all a definition of my setup:

· 3 x Play 1

· 1 x Play 3

· 2 x Play 5

· 2 x bridge – each connected to the router/wired network

· 1 x connect

· 1 x ipod interface

· 3 x ct100 controllers

Sonos is configured to use its own network and not my normal WiFi

Latest version of firmware installed.

Node-Sonos-http-api setup:

· Installed on Raspi using latest Raspidan. All updates installed before testing

· Latest versions of Node-Sonos downloaded from GitHub and installed before testing

· NodeJS is version 12.1

From what I can see it appears to be a timing issue. These are the tests I have run and the results…

Test 1:

Group 2 players together (“Office” and “Patio”). Office is the coordinator (I think) Set them to playing a radio station.

In a browser execute the following command http://192.168.0.30:5005/Patio/say/hallo

Monitor what happens in the SONOS GUI running on a PC

Results for Test 1:

Works ca 80% of the time!

In the GUI you can observe:

· the group being split apart

· Radio station is still playing on both speakers

· Radio station stops playing on the Patio speaker

· Speech file being added to the Patio player.

· text being spoken on the Patio Speaker (Office speaker still playing radio stream)

· text completes and then the two players are placed back in the group

· Both speakers playing the Radio Stream.

Test 2:

Same as test 1 but using the Office speaker to output the text instead of the Patio Speaker.

Results for Test 2:

As for test 1 – except of course the speakers used are reversed.

Again works most of the time but fails ca 20% of the time.

When it fails I notice that the speech is being output on the speaker before the split of the group has occurred (This could be expected to some extent as the GUI is async to what is happening in the API. The group is never restored and the speech file is never returned back to the radio station. That speaker output no further sound.

Test 3:

Same as previous tests but running an mp3 file from the queue as the source.

Results of Test 3:

Very strange 70% of the time you don’t hear the text being spoken – even though you see the group being split and the file loaded.

80% of the time the group is reformed. The rest of the time not.

Restarted the api and tried test 3 again. Speech was output this time. But group failed to reform after playing. 100% failure rate on 10 tries.

Test 4:

This time using all speakers. No groups. Sources playing on some speaker, others stopped. All speakers have a source (radio or mp3) regardless of if it is playing.

Using the http://192.168.0.30:5005/sayAll/Hallo

Results test 4:

All speakers built into a group. Speech plays. Group is split apart. 4 of the 6 players get restored to their previous states (repeatable for the 10 tests I tried).

Test 5:

Two speakers are already in a group (as for test 1). Again using the “sayAll” command.

Results test 5:

Group is created with all speakers. Speech is output. Group does not split apart again. Original state not restored.

Test 6:

Single speaker. Not in group. Playing either radio station or mp3 file. Using the command http://192.168.0.30:5005/Patio/say/hallo

Results of Test 6:

Speech file is loaded and output. Original source is not returned to (although volume does appear to get set back!) 100% repeatable. Once or twice I have had it not increase the volume when outputting the speech.

Too me it looks very much like it’s a synchronization/event handling problem. Things are not happening in the order they should (or are expected to). The basic functionality appears to work given that it sometimes does what it is supposed to – but it is not reliable and can leave the speakers is an undesirable state. The load on the Raspi seems to be OK - peaks about 80%.

Don’t know if that helps you.

Let me know if there is anything else I should try.

Peter

From: Jimmy Shimizu [mailto:notifications@github.com] Sent: Monday, June 01, 2015 16:44 To: jishi/node-sonos-http-api Cc: ppitkin Subject: Re: [node-sonos-http-api] restore state after say / sayAll (#34)

Hi, to follow up on the questions raised here and in #56 https://github.com/jishi/node-sonos-http-api/issues/56 :

I have had very little time left over in the last year to work on this. Hopefully I will have some time in late June and a couple of months since I will be in between jobs and might become a bit bored on my vacation.

Regarding the restoration, since the sayAll still suffers from some issues, these needs to be resolved before it will be fully functional, even for the say command. I have a few ideas on whats wrong, primarily for the radio feeds. The URI that is storeas as AVTransport doesn't not correlate with the actual URI that it wants when restoring the state (the transport URI is set to the actual http URL for the stream), but is part of the radio metadata (an x-sonos-stream: uri), so this needs to be considered when storing the previous state somehow. Invoking that uri instead, triggers the appropriate meta data fetch and radios should resume correctly.

— Reply to this email directly or view it on GitHub https://github.com/jishi/node-sonos-http-api/issues/34#issuecomment-107538923 . https://github.com/notifications/beacon/AKyrHD2wdihnJVpvPTptf7AtGW5hnagDks5oPGcugaJpZM4DWeBr.gif

[jishi]

@ppitkin Thanks for this, it's very helpful. Especially anything that is reproducible most of the time. You are right in the theory that there is a timing/event issue. Although I already made some fixes to try and mitigate it, there is still some issues with commands (grouping etc) that doesn't come through, as well as events that goes missing (or is delayed), which becomes more apparent in big Sonos installations, and worse when you also suffer from wireless interference.

[thansen22]

First of all, nice work. I also have an ISY994i and after getting a Sonos setup I just knew someone had to have done something like this, thanks!

Second, I'm also primarily using the software to do TTS and have found the same issues as reported. I noticed that it often doesn't restore whatever was playing prior: TV/Amazon/Pandora are the 3 I ran into, but also predominantly use.

I modified say/sayall to take in another optional param for setting the volume (just after language). I'm planning to use this + the ISY to produce my own alarm system, with speech warnings before the alarm sounds. If it was super consistent I'd totally have it do much more, but if Echo/Sonos/ISY ever get along that may solve the majority of my desires.

[madspoulsen]

Thansen22, That volume parameter sounds pretty useful. Can you upload the file or addition?

[riemers]

Any updates on this? I just sayall, but it didn't restore my stream. I also tried to just do a play from uri which makes it in the que, but i have to issue a play after that. Still not a big issue but i can't restore my que. Was mainly going to use it for announcements too. (same for pauseall/resumeall)

[tnemrap]

any update on this?

/Mike

[jishi]

Sadly no. I'm considering a major rewrite of the base code and try to introduce builtin retry-logic for actions that don't finish correctly. I hope that would make it more resilient. However, I don't have a time frame when this will be finished.

[jishi]

It now restores again, but with some gotchas:

If phrase is very short, I can't seem to identify the state change quick enough so it will not restore. If say is invoked twice during the last say operation is still in play, it will try to restore to the current say command, which is not what you want, probably.

I also switched to voicerss.org, so you need to register for an API key to make it functional. Let me know your feedback in this issue.