Announcement

Collapse
No announcement yet.

Questions about TTS

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Questions about TTS

    The plug-in is working fine with regard to controlling the speakers, but I am struggling with some aspects of TTS.

    I had a whole house audio system planned using Russound or Monoprice distribution amplifiers, but i was overridden by my better half as she didn't want more holes in the walls and ceilings. I purchased a couple of Play 3 speakers to start and was very happy with the results. I think the Sonos ecosystem is very well executed, both in function and sound quality. I purchased a batch of broken Play 5 speakers and have managed to repair 4 of them, with hopes of repairing 2 more if I can find schematics and parts. I added another used Play 3 and am trying to purchase a couple of Connect
    :Amps for the back yard.

    The increase in clients has mitigated some of the problems, but has amplified others. I have some specific problems to address.
    • I have created a number of linkgroups for announcements and alerts. They are working well, except when I want to include some Android clients in the mix. If I intercept speaker device 0 as below, the speech will come out of all devices.

      Click image for larger version

Name:	Capture1.png
Views:	1
Size:	32.2 KB
ID:	1210112

      The problem is that I usually play an alert wave file before announcements. This file is different, depending on the type of announcement. If I put the wave file in one speak action and the text to speak in another, the Sonos devices have a huge delay between the wave file and the test spoken. If I put it in the format that the plug-in likes
      Code:
      c:\Program Files (x86)\HomeSeer HS3\Wave\Chime2.wav|$$DTR:8850: <silence msec='500'/> The time is $$time <silence msec='250'/> the temperature is $$DVR:3695:
      the Android clients treat the path and file for the alert tone literally, reading it as text instead of playing the file. This is likely a limitation of the HS3 speaker proxy, but maybe I am missing something. If I create different speech events for the Sonos and Android clients the delays between the devices can become a problem.
    • The second issue is announcement volumes and destination devices for Sonos. There are times I may want to announce to all clients, and others where I might only want some. There are times I would like to have them at different levels than the defaults sent in the Linkgroup as above. I have created three linkgroups that take care of different levels, mute actions and devices included, but that is too limiting. I would probably need ten or more linkgroups to take care of the variables. If I run a separate action to control the volumes and mute status prior to the announcement, but that affects restoration of the levels prior to the announcement. It would be very useful if we could send the levels and mute override for each individual client for any announcement so that the plug-in could easily make an announcement in any room at any level, overriding mute if needed and then returning all clients to their state before the announcement.
    • There seems to be a problem if multiple announcements are sent to the Sonos linkgroups in succession, the first one plays well, but the later ones can be seriously delayed and even ignored. Are there any suggestions as to reducing or eliminating these problems? It seems to ba caused by the plug-in's delay unlinking the speakers and making them available after an announcement. There is usually about 5 seconds of silence before an announcement and 10 seconds after an announcement before the speaker clients return to what they were doing before.
    • If Pandora is playing and an announcement is made, the song is paused, the announcement made and Pandora starts a new song. Amazon, Deezer and others do not seem to have this problem. I can manually pause and restart Pandora without this issue.
    A solution to some of these problems would be the ability to dynamically set up a linkgroup within an event. The linkgroup could be set to specifically determine which clients play, what their level will be and whether or not mute is respected on the client. If there is already the means to do this, I am all ears. If it could be done by scripting calls, I would be interested in learning. The only other alternative I can think of is to build a number of linkgroups with these settings baked in, then directing the announcement to the proper linkgroup, depending on conditions.
    HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

    #2
    Originally posted by rprade View Post
    The plug-in is working fine with regard to controlling the speakers, but I am struggling with some aspects of TTS.

    I had a whole house audio system planned using Russound or Monoprice distribution amplifiers, but i was overridden by my better half as she didn't want more holes in the walls and ceilings. I purchased a couple of Play 3 speakers to start and was very happy with the results. I think the Sonos ecosystem is very well executed, both in function and sound quality. I purchased a batch of broken Play 5 speakers and have managed to repair 4 of them, with hopes of repairing 2 more if I can find schematics and parts. I added another used Play 3 and am trying to purchase a couple of Connect
    :Amps for the back yard.

    The increase in clients has mitigated some of the problems, but has amplified others. I have some specific problems to address.
    • I have created a number of linkgroups for announcements and alerts. They are working well, except when I want to include some Android clients in the mix. If I intercept speaker device 0 as below, the speech will come out of all devices.

      [ATTACH]57165[/ATTACH]

      The problem is that I usually play an alert wave file before announcements. This file is different, depending on the type of announcement. If I put the wave file in one speak action and the text to speak in another, the Sonos devices have a huge delay between the wave file and the test spoken. If I put it in the format that the plug-in likes
      Code:
      c:\Program Files (x86)\HomeSeer HS3\Wave\Chime2.wav|$$DTR:8850: <silence msec='500'/> The time is $$time <silence msec='250'/> the temperature is $$DVR:3695:
      the Android clients treat the path and file for the alert tone literally, reading it as text instead of playing the file. This is likely a limitation of the HS3 speaker proxy, but maybe I am missing something. If I create different speech events for the Sonos and Android clients the delays between the devices can become a problem.
    • The second issue is announcement volumes and destination devices for Sonos. There are times I may want to announce to all clients, and others where I might only want some. There are times I would like to have them at different levels than the defaults sent in the Linkgroup as above. I have created three linkgroups that take care of different levels, mute actions and devices included, but that is too limiting. I would probably need ten or more linkgroups to take care of the variables. If I run a separate action to control the volumes and mute status prior to the announcement, but that affects restoration of the levels prior to the announcement. It would be very useful if we could send the levels and mute override for each individual client for any announcement so that the plug-in could easily make an announcement in any room at any level, overriding mute if needed and then returning all clients to their state before the announcement.
    • There seems to be a problem if multiple announcements are sent to the Sonos linkgroups in succession, the first one plays well, but the later ones can be seriously delayed and even ignored. Are there any suggestions as to reducing or eliminating these problems? It seems to ba caused by the plug-in's delay unlinking the speakers and making them available after an announcement. There is usually about 5 seconds of silence before an announcement and 10 seconds after an announcement before the speaker clients return to what they were doing before.
    • If Pandora is playing and an announcement is made, the song is paused, the announcement made and Pandora starts a new song. Amazon, Deezer and others do not seem to have this problem. I can manually pause and restart Pandora without this issue.

    A solution to some of these problems would be the ability to dynamically set up a linkgroup within an event. The linkgroup could be set to specifically determine which clients play, what their level will be and whether or not mute is respected on the client. If there is already the means to do this, I am all ears. If it could be done by scripting calls, I would be interested in learning. The only other alternative I can think of is to build a number of linkgroups with these settings baked in, then directing the announcement to the proper linkgroup, depending on conditions.
    Hi Randy,

    did you read up on all capabilities in the help file (tools->help->sonos)?

    My recommendation would be to create x linkgroups, even if that means many. People create hundreds of events so doing a bunch of linkgroups might not be the most perfect but it should be proven.

    The reason I advocate linkgroups is because over the years I tried to optimize the flow to make it react as quick as possible, which unfortunately means that some actions actually needed to be delayed as a barrage of commands appeared to get lost, especially when you have more players (hint: ALL Sonos devices let each other know ALL the time what they are doing so interplayer traffic increases exponential with # players). So if you were to all go script it, there is a good chance this will become your project for life.

    The PI support multiple announcement in parallel BUT one should be very careful with this. There are 2 very distinct categories:

    a/ multiple announcements happening for THE SAME linkgroup. The announcements actually get queued and should not trigger unlinking in between announcements UNLESS you are so unlucky that the unlinking already began when the next announcement for THE SAME linkgroup came in.
    b/ multiple announcement for DIFFERENT linkgroups. If the linkgroups deal with different players, all should work perfectly in parallel. IF the linkgroup overlap with participating players, you are very likely going to end up with a mess. It has all to do with the snapshot of existing configuration that gets created when the announcement start and re-established when it ends. Example: announcement 1 has Kitchen player as part of the linkgroup 1 and the state of what the kitchen player is doing is saved. Announcement 2 comes in for linkgroup 2 so now the kitchen player state which is dealing with announcement 1 is now saved. Announcement 1 ends and the kitchen goes back to what is was doing before the announcement started but now announcement 2 ends and now the kitchen player is put in the state it was when it was playing announcement 1 and now your state is hosed.

    So if you could show me how your events are created, linkgroups you created and what you were doing, I could comment why it might have taken forever or you have a mess coming out of the announcement.

    I managed in the past to keep it simple enough but 100% predictable versus highly dynamic and unpredictable. Example: if you want to send an announcement to Sonos and to as speaker client: "add 2 speak actions to one event, one going to whatever Client and the other to whatever linkgroup", which also means no interception of device 0. Even if you write your own scripts, you will be challenged big time to avoid race conditions. Playing announcements is simple, save/restore state 100% reliable in a any-to-any parallel fashion would require a 100% holistic picture of what all players are doing, which events are in flight, which hierarchy of priority you may have built in etc etc.

    Check the help file on "post announcement actions". It was a function added a few years back when you have more than one proxy active and/or want to send announcements to your Sonos player AND to a client. I suspect you might be using that and see how the combined actions using the | separator might give you issues with speaker clients. I can have a look at that.

    Hope this helps a little, next step might be to break it down in discrete issues you want to solve with screen shots of everything that is involved for that discrete issue.

    Dirk

    Comment


      #3
      I intercept device 0 so that an announcement that doesn't specify a client will be played by all devices. On post announcement actions I forward all so that I can individually address my HSTouch clients and so they will work when an announcement is sent to all clients. If I send with no client defined, it is played by all Sonos and HSTouch clients. If I specify a linkgroup, it will only play to that linkgroup and if I specify an Android client, it goes only to that client. That part of it all works reliably and predictably except for a timing difference between Sonos and other clients.

      I have been able to prove that there is 3-5 seconds of delay before any linkgroup directed TTS and about the same before the Sonos will resume playing after the end of TTS. Sometimes the Sonos delay is 4-5 seconds longer, really throwing things out of sync. The HSTouch clients have no delays when the TTS is sent directly to them. If an announcement is sent with no client defined, the delays are across the board.

      I've gone to multiple linkgroups, most of which handle all of the Sonos devices, with a variance in volumes, mute override, etrc. I currently have 7 Sonos speakers (4x Play 5 and 3x Play 3) in 6 rooms - one is a stereo pair. Using the multiple linkgroups is very cumbersome, but it is functioning. You can imagine the number of linkgroups are required when you are controlling 2-3 parameters on 7 devices.

      ANOTHER ISSUE: I am getting persistent errors, probably about half of the time I generate a TTS announcement. Here is a sample of the errors:

      Oct-27 9:00:06 AM Sonos Error ERROR in PlayURI for zoneplayer = Living Room with UPNP Error = Read only tag / Transport is locked / Access denied. URI=x-rincon:RINCON_B8E937293C5C01400 and isObjectID = False, MetaData=http://192.168.2.36:80/images/Sonos/Announcement.jpgHomeSeer Announcementobject.item.audioItem.musicTrackDirk CorsusSonosControllerDirk Corsus, Error =MyUPnPService.InvokeAction for ServiceID = http://192.168.2.211:1400/xml/AVTransport1.xml while sending Action = SetAVTransportURI for URI = http://192.168.2.211:1400/MediaRende...nsport/Control and Request = 0 x-rincon:RINCON_B8E937293C5C01400 <DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:r="urn:schemas-rinconnetworks-com:metadata-1-0/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"><item id="-1" parentID="-1" restricted="true"><upnp:albumArtURI>http://192.168.2.36:80/images/Sonos/Announcement.jpg</upnp:albumArtURI><dc:title>HomeSeer Announcement</dc:title><upnp:class>object.item.audioItem.musicTrack</upnp:class><dc:creator>Dirk Corsus</dc:creator><upnp:album>SonosController</upnp:album><r:albumArtist>Dirk Corsus</r:albumArtist></item></DIDL-Lite> UPNP Error = faultcode = s:Client, faultstring = UPnPError, detail = 501 with error = The remote server returned an error: (500) Internal Server Error.
      Oct-27 9:00:03 AM Sonos Error ERROR in PlayURI for zoneplayer = Guest Room with UPNP Error = Read only tag / Transport is locked / Access denied. URI=x-rincon:RINCON_B8E937293C5C01400 and isObjectID = False, MetaData=http://192.168.2.36:80/images/Sonos/Announcement.jpgHomeSeer Announcementobject.item.audioItem.musicTrackDirk CorsusSonosControllerDirk Corsus, Error =MyUPnPService.InvokeAction for ServiceID = http://192.168.2.206:1400/xml/AVTransport1.xml while sending Action = SetAVTransportURI for URI = http://192.168.2.206:1400/MediaRende...nsport/Control and Request = 0 x-rincon:RINCON_B8E937293C5C01400 <DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:r="urn:schemas-rinconnetworks-com:metadata-1-0/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"><item id="-1" parentID="-1" restricted="true"><upnp:albumArtURI>http://192.168.2.36:80/images/Sonos/Announcement.jpg</upnp:albumArtURI><dc:title>HomeSeer Announcement</dc:title><upnp:class>object.item.audioItem.musicTrack</upnp:class><dc:creator>Dirk Corsus</dc:creator><upnp:album>SonosController</upnp:album><r:albumArtist>Dirk Corsus</r:albumArtist></item></DIDL-Lite> UPNP Error = faultcode = s:Client, faultstring = UPnPError, detail = 501 with error = The remote server returned an error: (500) Internal Server Error.


      This error can be on any of the devices, it is not always the same one. There are generally 20-30 spoken announcements in a day and there will be an error or two on about half. When it happens, TTS comes out of the rest of the speakers, but is not heard in the ones with the error. When this happens all of the Sonos devices can be playing or idle, grouped or ungrouped - it doesn't matter.

      Any ideas what these errors are and how to prevent them?
      Last edited by randy; October 27, 2016, 04:46 PM.
      HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

      Comment


        #4
        Originally posted by rprade View Post
        I intercept device 0 so that an announcement that doesn't specify a client will be played by all devices. On post announcement actions I forward all so that I can individually address my HSTouch clients and so they will work when an announcement is sent to all clients. If I send with no client defined, it is played by all Sonos and HSTouch clients. If I specify a linkgroup, it will only play to that linkgroup and if I specify an Android client, it goes only to that client. That part of it all works reliably and predictably except for a timing difference between Sonos and other clients.

        I have been able to prove that there is 3-5 seconds of delay before any linkgroup directed TTS and about the same before the Sonos will resume playing after the end of TTS. Sometimes the Sonos delay is 4-5 seconds longer, really throwing things out of sync. The HSTouch clients have no delays when the TTS is sent directly to them. If an announcement is sent with no client defined, the delays are across the board.

        I've gone to multiple linkgroups, most of which handle all of the Sonos devices, with a variance in volumes, mute override, etrc. I currently have 7 Sonos speakers (4x Play 5 and 3x Play 3) in 6 rooms - one is a stereo pair. Using the multiple linkgroups is very cumbersome, but it is functioning. You can imagine the number of linkgroups are required when you are controlling 2-3 parameters on 7 devices.

        ANOTHER ISSUE: I am getting persistent errors, probably about half of the time I generate a TTS announcement. Here is a sample of the errors:

        Oct-27 9:00:06 AM Sonos Error ERROR in PlayURI for zoneplayer = Living Room with UPNP Error = Read only tag / Transport is locked / Access denied. URI=x-rincon:RINCON_B8E937293C5C01400 and isObjectID = False, MetaData=http://192.168.2.36:80/images/Sonos/Announcement.jpgHomeSeer Announcementobject.item.audioItem.musicTrackDirk CorsusSonosControllerDirk Corsus, Error =MyUPnPService.InvokeAction for ServiceID = http://192.168.2.211:1400/xml/AVTransport1.xml while sending Action = SetAVTransportURI for URI = http://192.168.2.211:1400/MediaRende...nsport/Control and Request = 0 x-rincon:RINCON_B8E937293C5C01400 <DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:r="urn:schemas-rinconnetworks-com:metadata-1-0/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"><item id="-1" parentID="-1" restricted="true"><upnp:albumArtURI>http://192.168.2.36:80/images/Sonos/Announcement.jpg</upnp:albumArtURI><dc:title>HomeSeer Announcement</dc:title><upnp:class>object.item.audioItem.musicTrack</upnp:class><dc:creator>Dirk Corsus</dc:creator><upnp:album>SonosController</upnp:album><r:albumArtist>Dirk Corsus</r:albumArtist></item></DIDL-Lite> UPNP Error = faultcode = s:Client, faultstring = UPnPError, detail = 501 with error = The remote server returned an error: (500) Internal Server Error.
        Oct-27 9:00:03 AM Sonos Error ERROR in PlayURI for zoneplayer = Guest Room with UPNP Error = Read only tag / Transport is locked / Access denied. URI=x-rincon:RINCON_B8E937293C5C01400 and isObjectID = False, MetaData=http://192.168.2.36:80/images/Sonos/Announcement.jpgHomeSeer Announcementobject.item.audioItem.musicTrackDirk CorsusSonosControllerDirk Corsus, Error =MyUPnPService.InvokeAction for ServiceID = http://192.168.2.206:1400/xml/AVTransport1.xml while sending Action = SetAVTransportURI for URI = http://192.168.2.206:1400/MediaRende...nsport/Control and Request = 0 x-rincon:RINCON_B8E937293C5C01400 <DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:r="urn:schemas-rinconnetworks-com:metadata-1-0/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"><item id="-1" parentID="-1" restricted="true"><upnp:albumArtURI>http://192.168.2.36:80/images/Sonos/Announcement.jpg</upnp:albumArtURI><dc:title>HomeSeer Announcement</dc:title><upnp:class>object.item.audioItem.musicTrack</upnp:class><dc:creator>Dirk Corsus</dc:creator><upnp:album>SonosController</upnp:album><r:albumArtist>Dirk Corsus</r:albumArtist></item></DIDL-Lite> UPNP Error = faultcode = s:Client, faultstring = UPnPError, detail = 501 with error = The remote server returned an error: (500) Internal Server Error.


        This error can be on any of the devices, it is not always the same one. There are generally 20-30 spoken announcements in a day and there will be an error or two on about half. When it happens, TTS comes out of the rest of the speakers, but is not heard in the ones with the error. When this happens all of the Sonos devices can be playing or idle, grouped or ungrouped - it doesn't matter.

        Any ideas what these errors are and how to prevent them?
        Sorry no idea what causes the errors.
        Could you add screenshots of all linkgroups and how your events are structured.
        What are the chances that you have overlapping announcements for different linkgroups?
        You could turn the debug flag on, leave it on, after a day, go hunt for the errors and cut/paste 5 minutes prior to the announcement and 1 minute post it and email me or zip it and post it.

        Dirk

        Comment


          #5
          Originally posted by dcorsus View Post
          Sorry no idea what causes the errors.
          Could you add screenshots of all linkgroups and how your events are structured.
          What are the chances that you have overlapping announcements for different linkgroups?
          You could turn the debug flag on, leave it on, after a day, go hunt for the errors and cut/paste 5 minutes prior to the announcement and 1 minute post it and email me or zip it and post it.

          Dirk
          For the last two days, while chasing down the errors, I am running a single event that speaks the time and temperature on the hour. The event is:

          Click image for larger version

Name:	Capture1.jpg
Views:	1
Size:	24.8 KB
ID:	1187554

          The above event is called by another trigger event. The linkgroups are here:

          Click image for larger version

Name:	Capture.jpg
Views:	1
Size:	94.6 KB
ID:	1187553

          The speak time event only speaks to the group "ALL". There are no other events and there have never been simultaneous speak events.

          I will post a debug file as soon as I can.
          HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

          Comment


            #6
            Originally posted by rprade View Post
            For the last two days, while chasing down the errors, I am running a single event that speaks the time and temperature on the hour. The event is:

            [ATTACH]57275[/ATTACH]

            The above event is called by another trigger event. The linkgroups are here:

            [ATTACH]57274[/ATTACH]

            The speak time event only speaks to the group "ALL". There are no other events and there have never been simultaneous speak events.

            I will post a debug file as soon as I can.
            I know you are not using the linkgroup "time" but remember that the name is case sensitive so it wouldn't work as is.

            The reason it takes 3~4 seconds is just the delays to save everything and reconfigure which as I wrote before becomes worse the more players you have because all players inform each other. So the only thing that I can think of right now, is that perhaps I'm still going to fast. There are a bunch of delays built in and the delays are dynamic based on how many players are involved. It was done because actions would go lost (typically just lost no errors though!!).

            So I asked about announcement in parallel, I read "none", but are there other actions/events in your system that do something with the players (ex: link, unlink, group, set volume, set state etc?). Typically when I get the error you see, it is almost always that the player is not in the right state where it accepts to be told to play something. So either I have overlooked some state (and the log should show me that) or I'm going to fast or something else going on at the same time. I need to ask, because on more than one occasion after posting back and forth (or look at a trace) I find out that something else was going on that the author forgot to mention

            What PI version are you on?

            Dirk

            Comment


              #7
              Originally posted by dcorsus View Post
              I know you are not using the linkgroup "time" but remember that the name is case sensitive so it wouldn't work as is.

              The reason it takes 3~4 seconds is just the delays to save everything and reconfigure which as I wrote before becomes worse the more players you have because all players inform each other. So the only thing that I can think of right now, is that perhaps I'm still going to fast. There are a bunch of delays built in and the delays are dynamic based on how many players are involved. It was done because actions would go lost (typically just lost no errors though!!).

              So I asked about announcement in parallel, I read "none", but are there other actions/events in your system that do something with the players (ex: link, unlink, group, set volume, set state etc?). Typically when I get the error you see, it is almost always that the player is not in the right state where it accepts to be told to play something. So either I have overlooked some state (and the log should show me that) or I'm going to fast or something else going on at the same time. I need to ask, because on more than one occasion after posting back and forth (or look at a trace) I find out that something else was going on that the author forgot to mention

              What PI version are you on?

              Dirk
              I am running version 3.1.0.16

              When I initially was having problems, I was playing with the volume, mute and all sorts of stuff. Now that I am troubleshooting the errors, I have pared it down to a single event, that I posted a screenshot of above. There are no other Sonos controlling events of any kind. The error occurs 2-7 times a day when just speaking the time. It speaks the time 16 times between 7:00 AM and 10:00 PM

              There are absolutely no other Sonos events in my system. I am just trying to get announcements to work reliably. We control the Sonos from iOS applications, but for the last two days, they have been silent so there are no conflicts of any kind with plug-in actions.

              I was unaware that the names were case sensitive, but I am using $SONOS$TIME$ as the speaker client as you can see in the event screenshot. The event does speak to the "Time" linkgroup without fail. When it does speak the time and temperature, about half the time it goes to all 7 speakers, the other half of the time when I get errors, the speak event does not go to the one or two clients that show the error, but does go to the rest.

              While not relative to the plug-in, controlling these speakers from the app has shown no anomalies of failing to group or ungroup. With the iOS app, they just work.

              I will try to capture and post debug information tomorrow.
              HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

              Comment


                #8
                Originally posted by rprade View Post
                I am running version 3.1.0.16

                When I initially was having problems, I was playing with the volume, mute and all sorts of stuff. Now that I am troubleshooting the errors, I have pared it down to a single event, that I posted a screenshot of above. There are no other Sonos controlling events of any kind. The error occurs 2-7 times a day when just speaking the time. It speaks the time 16 times between 7:00 AM and 10:00 PM

                There are absolutely no other Sonos events in my system. I am just trying to get announcements to work reliably. We control the Sonos from iOS applications, but for the last two days, they have been silent so there are no conflicts of any kind with plug-in actions.

                I was unaware that the names were case sensitive, but I am using $SONOS$TIME$ as the speaker client as you can see in the event screenshot. The event does speak to the "Time" linkgroup without fail. When it does speak the time and temperature, about half the time it goes to all 7 speakers, the other half of the time when I get errors, the speak event does not go to the one or two clients that show the error, but does go to the rest.

                While not relative to the plug-in, controlling these speakers from the app has shown no anomalies of failing to group or ungroup. With the iOS app, they just work.

                I will try to capture and post debug information tomorrow.
                I'd bet you the reason the "time" event works is because your "all" linkgroup intercepts pretty much all announcements. Remove the "device intercept" from the "all" linkgroup and try your "time" event again.

                I never wrote that the problem is with linking , I wrote the problem is what the PI does and how I try to do as much in parallel and asynchronously as possible.

                Dirk

                Comment


                  #9
                  Originally posted by dcorsus View Post
                  I'd bet you the reason the "time" event works is because your "all" linkgroup intercepts pretty much all announcements. Remove the "device intercept" from the "all" linkgroup and try your "time" event again.

                  I never wrote that the problem is with linking , I wrote the problem is what the PI does and how I try to do as much in parallel and asynchronously as possible.

                  Dirk
                  Nope. I tested this a few weeks ago as I was trying to understand your proxy. I just now verified it again. This is true of events that speak as well as hs.speak scripting calls.
                  • If the speak event has no speaker client identified, it will speak to linkgroup "All" (where the Intercept is set to 0) as well as all HSTouch clients. If I remove "0" from the "All" linkgroup the Sonos speakers are silent, but the HSTouch clients still speak. With 0 as the intercept device, "All" will only speak when there is no client specified in the speech event or if $SONOS$ALL$ is one of the named clients. If the speech event calls any client that is not specifically a Sonos linkgroup, it is ignored by the PI and passed to the rest of the HS clients to look for a match.
                  • If I direct speech to $SONOS$TIME$ it is handled by the "Time" linkgroup, regardless of the case. I tried "Time", "TIME" and "time" and they all worked. Just for the sake of consistency, I made my linkgroups all uppercase and will configure events and scripts to do the same.


                  I spent the better part of a weekend testing and studying and I am fairly certain I am able to predict exactly where sound should come out based upon how I add clients to the event.

                  All I am trying to do is figure out why it intermittently fails (with errors) on the Sonos clients only. I have been using 3 Android clients for a year and they handled (and continue to handle) announcements without even a hiccup. Most of my announcements continue to be directed to those clients unless/until I can see that the Sonos is reliable.
                  HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

                  Comment


                    #10
                    Randy - I had similar issues with a couple of Sonos units. The Sonos app from my iPhone always linked things a played fine, but the plugin would sometimes not work on one or two units when making announcements. All my units are hardwired because I had the cat5e already there.

                    If you're running all of them wifi you can stop reading.

                    After looking through the Sonos forum I found a post saying that hardwiring the units did not disable the wifi and that they would continue to communicate with each other via wifi unless you disabled it for each unit. Once I did that, I didn't have any other problems.

                    https://bsteiner.info/articles/disabling-sonos-wifi

                    Comment


                      #11
                      I am running them as a SonosNet with one speaker connected to the wired network. Prior to that when I only had three speakers it was all WiFi. I am not positive, but I don't think as many (if any) errors. But I went to 7 speakers from 3, so I have no way of knowing if it was the network configuration or more than doubling the clients that made these problems appear.

                      I have no desire to wire all of the speakers and it was my understanding that when using a single Ethernet connection, the rest of the speakers are then connected through SonosNet on the channel designated. My SonosNet is on channel 1 and my Router is on 6. This is all on 2.4G. The bulk of my household is on 5G.

                      I also thought that STP problems were only when more than 1 speaker has a wired connection.

                      I am not sure if a loop could be created with a single wired connection is in the mix, but I think it might be possible. I could eliminate that possibility by reverting to a pure WiFi configuration.
                      Last edited by randy; October 28, 2016, 08:13 AM.
                      HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

                      Comment


                        #12
                        Originally posted by rprade View Post
                        I am running them as a SonosNet with one speaker connected to the wired network. Prior to that when I only had three speakers it was all WiFi. I am not positive, but I don't think as many (if any) errors. But I went to 7 speakers from 3, so I have no way of knowing if it was the network configuration or more than doubling the clients that made these problems appear.

                        I have no desire to wire all of the speakers and it was my understanding that when using a single Ethernet connection, the rest of the speakers are then connected through SonosNet on the channel designated. My SonosNet is on channel 1 and my Router is on 6. This is all on 2.4G. The bulk of my household is on 5G.

                        I also thought that STP problems were only when more than 1 speaker has a wired connection.

                        I am not sure if a loop could be created with a single wired connection is in the mix, put I think it might be possible. I could eliminate that possibility by reverting to a pure WiFi configuration.
                        Don't go wiring up speakers, just a log would be a good start to look at the issue.

                        Dirk

                        Comment


                          #13
                          Originally posted by dcorsus View Post
                          Don't go wiring up speakers, just a log would be a good start to look at the issue.

                          Dirk
                          I'm going to look for errors and get you log info today if possible.

                          I wasn't thinking of wiring the speakers, just disconnecting the one and going back to pure WiFi. I really don't see how the network configuration could only affect the plug-in function.
                          HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

                          Comment


                            #14
                            I just enabled time announcements. The first announcement caused the same error and the Living Room and Guest Room speakers were silent. Guest Room is a Play 3, Living Room a Play 5 (Gen 1). The debug logs are attached.

                            I manually ran the event at 1:13 and there were no errors or skipped clients.

                            EDIT: sonosdebug.txt is when there was an error and sonosdebug1.txt is when the announcement worked properly.
                            Attached Files
                            Last edited by randy; October 28, 2016, 02:06 PM.
                            HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

                            Comment


                              #15
                              Originally posted by rprade View Post
                              I just enabled time announcements. The first announcement caused the same error and the Living Room and Guest Room speakers were silent. Guest Room is a Play 3, Living Room a Play 5 (Gen 1). The debug logs are attached.

                              I manually ran the event at 1:13 and there were no errors or skipped clients.

                              EDIT: sonosdebug.txt is when there was an error and sonosdebug1.txt is when the announcement worked properly.
                              Randy, any chance to grab a minute before your start in the Sonosdebug.txt file, ie start from 12:59:00. The announcement was already in progress, I want to see the log starting from the speakIn log entry to 1:00:00.

                              Just to double check, you don't have a playbar in here do you? What kind of player is the master bedroom? Which one is wired? One thing to try is to pick another player as source, just to test, preferable a central located player and/or the wired player.

                              Hmm, looking further through the trace ..... I also noted another announcement starting at 1:00:14 , hmm ...

                              So post the whole log file at least from lets say 12:55:00 through 1:05:00 to see what is going on.

                              Thanks

                              Comment

                              Working...
                              X