Announcement

Collapse
No announcement yet.

SonosController Plug-In Beta testing Forum

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

    #16
    Originally posted by mark_anderson_us View Post
    Hi Dirk

    I installed 44 last week and am having a few issues

    in HS web view I see status Ok and can control devices (but linked zones don;t show what's playing there: not sure if this is normal)

    In HSTouch designer, I only see 2 out of 5 devices.
    Mark,

    could you turn debug on, start HS and let it come up and email me the log. Are some of these players, wireless or separated from the HS PC by a router, are they perhaps in another subnet? My first gut feel would be that the plug-in has not detected 3 out of 5 because for some reason it can't reach them (or firewall perhaps?). I did make a bunch of changes on the discovery but would be surprised if I broke that functionality somehow. If you take the S5 off-line (which I assume you use wireless?) does it make a difference?

    Dirk

    Comment


      #17
      error on link

      some errors on linking, fails to add some zones.
      all players/controllers on same subnet and functioning fine

      attempting to link party zone group

      here is the error and then an attachment of a chunk of the logs. no errors on homeseer startup and linking works sometimes but it is hit and miss.

      11/25/2010 12:47:00 PM ~!~SONOSCONTROLLER~!~ERROR in PlayURI for zoneplayer = HomeSeer with UPNP Error = UPNP_E_INVALID_ARGUMENTS . URI=x-rincon:RINCON_000E5811101A01400, MetaData= Error =System.Runtime.InteropServices.COMException (0x80040208): A user-supplied component or subscriber raised an exception (Exception from HRESULT: 0x80040208) at UPNPLib.IUPnPService.InvokeAction(String bstrActionName, Object vInActionArgs, Object& pvOutActionArgs) at HSPI_SONOSCONTROLLER.HSMusicAPI.PlayURI(String URI, String MetaData)
      Attached Files

      Comment


        #18
        Originally posted by mbdirtfarmer View Post
        some errors on linking, fails to add some zones.
        all players/controllers on same subnet and functioning fine

        attempting to link party zone group

        here is the error and then an attachment of a chunk of the logs. no errors on homeseer startup and linking works sometimes but it is hit and miss.

        11/25/2010 12:47:00 PM ~!~SONOSCONTROLLER~!~ERROR in PlayURI for zoneplayer = HomeSeer with UPNP Error = UPNP_E_INVALID_ARGUMENTS . URI=x-rincon:RINCON_000E5811101A01400, MetaData= Error =System.Runtime.InteropServices.COMException (0x80040208): A user-supplied component or subscriber raised an exception (Exception from HRESULT: 0x80040208) at UPNPLib.IUPnPService.InvokeAction(String bstrActionName, Object vInActionArgs, Object& pvOutActionArgs) at HSPI_SONOSCONTROLLER.HSMusicAPI.PlayURI(String URI, String MetaData)
        Looking at the log, I have the impression that some of the zones that are being linked are already linked in some other configuration. Could you email me how they are linked and email me your .ini file. In the mean time I'm going to try something. Could it be that your source zone is linked to it's audio input and you are trying to link the other players to this source players. Should work of-course, not sure I tried it, but could be misinterpreting your traces as I don't have the .ini file which holds the UDNs of the zone players and the linkgroup configurations.

        Would also like to have the full HS log. Have the suspicion that either there was twice a link-on event and not a Unlink or the previous unlink was not successful, so the full HS log will help with that.


        Thanks and happy Thanksgivings

        Dirk
        Last edited by dcorsus; November 25, 2010, 07:20 PM.

        Comment


          #19
          Originally posted by dcorsus View Post
          Looking at the log, I have the impression that some of the zones that are being linked are already linked in some other configuration. Could you email me how they are linked and email me your .ini file. In the mean time I'm going to try something. Could it be that your source zone is linked to it's audio input and you are trying to link the other players to this source players. Should work of-course, not sure I tried it, but could be misinterpreting your traces as I don't have the .ini file which holds the UDNs of the zone players and the linkgroup configurations.

          Thanks and happy Thanksgivings

          Dirk
          Yes it could very well be linking already linked etc without unlinking first. I will try duplicate these issues and email you my ini file. It will have to wait, i'm going to be away for a few days and you should be enjoying your thanksgiving as well. Take a fews day break from decoding log files.

          Cheers and happy thanksgiving to you to.
          --
          Alan

          Comment


            #20
            Originally posted by mbdirtfarmer View Post
            Yes it could very well be linking already linked etc without unlinking first. I will try duplicate these issues and email you my ini file. It will have to wait, i'm going to be away for a few days and you should be enjoying your thanksgiving as well. Take a fews day break from decoding log files.

            Cheers and happy thanksgiving to you to.
            --
            Alan
            Just email the full HS log you have when it happened and the ini file, no need to duplicate.

            Dirk

            Comment


              #21
              New beta V1.0.0.47 posted

              Changes to V1.0.0.47:
              • Added full configuration support via on-line web pages
              • Added Mute Override option for TTS/Music Linkgroups. This will allow you to chose to unmute a zone when you link zoneplayers for TTS or Musics
              • Added creating back-ups of the .ini file. Each time you save your configuration a back-up will be created in the <HS root>\Configs sub-directory allowing you to manually restore your configuration if something went wrong or you accidentally deleted something.


              If no major issues pop up before the end of the week, then this version will go on the Updater.

              Comment


                #22
                New beta V1.0.0.48 posted

                Added support for selecting Line input as source to play.

                Comment


                  #23
                  New beta .51 posted. Queue announcements and no more need for Audio In !!

                  Changes to V1.0.0.51:
                  • Fixed bug when long strings are used in the.ini file caused by many zones and/or long zone names
                  • Fixed bug in Un-muting zones when TTS announcement is played
                  • Added minor delays when zones are linked for announcements to let the zoneplayer adjust to proper volume before streaming the announcement
                  • Added few methods to the API to set Alarm ON/OFF via scripts
                  • Fixed a bug in config screen where "Mute" indicator was always showing "On"
                  • Added queuing for Speaker Proxy announcements. This is quite a change so I could use some beta testers. If overlapping announcements come in via the speaker proxy, they will be queued and played one by one preventing multiple linking/unlinking events or moreover total linking mayhem
                  • Fixed a couple of issues with paired S5 speakers.
                  • Fixed a problem where an alarm trigger wouldn't fire if the TimeOfDay on your HS PC is different from the Sonos TimeOfDay
                  • Added one more trigger which will fire when the configuration of the zone players has changed (alarm changed, playlist changed, music DB changed, music re-indexed ...)
                  • Added the capability to add conditions to your triggers for event handling. Conditions are player : playing, stopped, paused, mutted
                  • Added the capability to stream announcements without physically being connected to a HS-PC. The plug-in can now stream an announcement (or any file) to a file and then have ANY player play the file, no more need to use audio line input. You could make your own announcements and steam those, they would be better quality then the HS Speaker

                  Comment


                    #24
                    New Beta .v53 posted fixing a bug with HS Touch

                    Changes to V1.0.0.53:
                    • Fixed a bug where only one zone player would show up in HSTouch
                    • Changed the default behavior when hs.Speakerex is called from a script. The announcement will now stream to a file and then played on the Linkgroup. Therefore no more need for a physical connection between HS and your Zone player. Note the old behavior won't work anymore but it should be 100% the same.

                    Comment


                      #25
                      Dirk,

                      I saw this:

                      Added the capability to stream announcements without physically being connected to a HS-PC. The plug-in can now stream an announcement (or any file) to a file and then have ANY player play the file, no more need to use audio line input. You could make your own announcements and steam those, they would be better quality then the HS Speaker
                      And thought that this is a great idea (one less connection), so I decided to install the beta and give it a go.

                      However, I soon realized it breaks my voice announcements, here is why.

                      I often listen to music on Sonos during the day while I am working. The way the old version worked, it would switch the Sonos input to the line in, play the message and switch back. As soon as the message was done, the system went right back to the music (right where it was). Now it seems the new message is a playlist, that overwrites the old playlist. No music after the playlist is done.

                      Another issue is that I have an event that switched the family room receiver back to TV input whenever the sonos system is stopped/paused. This way we just stop the music and we are set up for tv. Since the new plug-in plays a file and then stops, it triggers the receiver switch. So even if it did return to music it would not switch back my receiver.

                      I think this change is great for Sonos systems dedicated to HS, though unless you can think of a way to "get back" to what Sonos was doing before the message, for me it causes much more harm than good. Since this change may be useful for some, I think the best solution (if possible) is an option of calling the messages either way. Either a different script call, or an option flag in the setup.

                      I am also not get consistent results with this new method. It seems that usually (not always) the first part of the message is getting cut off. This happens even when I am already listening to a Sonos source.

                      So for now, I am (hopefully) rolling back to V1.0.0.50.

                      Lou

                      Comment


                        #26
                        Dirk,

                        I may need some help getting my system back up and working with V1.0.0.50 (or I am going to need to restore/roll vback my HS system). I put back the old dll and a copy of the "./html/sonoscontroller" I had saved and it does speak the messages, though it does not switch back to the original source after it is done.

                        Are there other files that were updated (I used the beta installer) that I need to roll back?

                        Lou

                        Comment


                          #27
                          Originally posted by gerlin View Post
                          The way the old version worked, it would switch the Sonos input to the line in, play the message and switch back. As soon as the message was done, the system went right back to the music (right where it was). Now it seems the new message is a playlist, that overwrites the old playlist. No music after the playlist is done.
                          The new version should do that as well. The fact that you see a playlist indicates that you have an announcement that consists of more then one part, perhaps a tone first, an announcement, followed by another tone. In case it is a single announcement, I'm not using the queue. It is correct that Sonos has a (simpler) treatment for linking to its audio input as it can switch without affecting what was in the queue. The plug-in was built that way to use that "little feature" and I suspect that I made an error in another part of the plug-in where the decision is being made to save the queue info or not.

                          Originally posted by gerlin View Post
                          Another issue is that I have an event that switched the family room receiver back to TV input whenever the sonos system is stopped/paused. This way we just stop the music and we are set up for tv. Since the new plug-in plays a file and then stops, it triggers the receiver switch. So even if it did return to music it would not switch back my receiver.
                          Is this the zone that had the audio-input connected or this is a participating zone? Never paid too much attention how these events were in the "old mode" but I can see indeed Sonos acting differently.

                          Originally posted by gerlin View Post
                          I think the best solution (if possible) is an option of calling the messages either way. Either a different script call, or an option flag in the setup.
                          I agree, I'm going to undo the change on speakex or find a way to allow one or the other.

                          Originally posted by gerlin View Post
                          I am also not get consistent results with this new method. It seems that usually (not always) the first part of the message is getting cut off. This happens even when I am already listening to a Sonos source.
                          I wonder what that is all about. Do you fading turned on or off? Don't seem to have this problem on my set-up but not so long ago noticed that Sonos takes it's merry time to change the volume levels. I added some code to wait for the volume change to happen, wonder in this case whether there is yet another "slowness" I should compensate for (or bypass).


                          Originally posted by gerlin View Post
                          I may need some help getting my system back up and working with V1.0.0.50 (or I am going to need to restore/roll vback my HS system). I put back the old dll and a copy of the "./html/sonoscontroller" I had saved and it does speak the messages, though it does not switch back to the original source after it is done. Are there other files that were updated (I used the beta installer) that I need to roll back?
                          I would go back to .51 which should not affect the hs.speakex functions. Apart from the DLL, see no other change required except that the installer/uninstaller might get a headache if you only overwrite the DLL. If you don't have the .51 installer files, I can email them when I'm home tonight. Not sure why it isn't switching back unless the original state was not correct to start with or maybe you changed something to the event itself?

                          Sorry for the issues

                          Dirk

                          Comment


                            #28
                            Dirk,

                            As usual, thanks for getting back to me so fast.

                            I ended up doing a Windows rollback to a system restore point. Perhaps I could have figured out why it was still misbehaving, though I had a very recent restore point and just wanted to get the system running properly.

                            Everything is back the way is was before the update. So there is no rush for anything here.

                            Originally Posted by gerlin
                            The way the old version worked, it would switch the Sonos input to the line in, play the message and switch back. As soon as the message was done, the system went right back to the music (right where it was). Now it seems the new message is a playlist, that overwrites the old playlist. No music after the playlist is done.
                            Originally Posted by dcorsus
                            The new version should do that as well. The fact that you see a playlist indicates that you have an announcement that consists of more then one part, perhaps a tone first, an announcement, followed by another tone. In case it is a single announcement, I'm not using the queue. It is correct that Sonos has a (simpler) treatment for linking to its audio input as it can switch without affecting what was in the queue. The plug-in was built that way to use that "little feature" and I suspect that I made an error in another part of the plug-in where the decision is being made to save the queue info or not.
                            I do not know is if this is relevant, though I was originally listening to Sirius when I first tested and noticed the problem, it did not restart Sirius. In the PC Sonos Desktop controller I could see the "announce.wav" (I think that was the name) still on the player. If I clicked play, it would play the announcement again (and the beginning of the text sent to speakEx was not played). I do not believe cross fade was enabled. I think I tried the same test with an "Imported Playlist", though I cannot swear to it. I did not test with a native Sonos Playlist.

                            Originally Posted by gerlin
                            Another issue is that I have an event that switched the family room receiver back to TV input whenever the sonos system is stopped/paused. This way we just stop the music and we are set up for tv. Since the new plug-in plays a file and then stops, it triggers the receiver switch. So even if it did return to music it would not switch back my receiver.
                            Originally Posted by dcorsus
                            Is this the zone that had the audio-input connected or this is a participating zone? Never paid too much attention how these events were in the "old mode" but I can see indeed Sonos acting differently.
                            This was on the node with the input. I have two zones. This one is a ZP-80 without an amplifier, so I switch the receiver whenever I play through the Sonos or make a voice announcement.

                            Originally Posted by gerlin
                            I am also not get consistent results with this new method. It seems that usually (not always) the first part of the message is getting cut off. This happens even when I am already listening to a Sonos source.
                            Originally Posted by dcorsus
                            I wonder what that is all about. Do you fading turned on or off? Don't seem to have this problem on my set-up but not so long ago noticed that Sonos takes it's merry time to change the volume levels. I added some code to wait for the volume change to happen, wonder in this case whether there is yet another "slowness" I should compensate for (or bypass).
                            I believe fading was off, with Sirius I suppose it may not matter, though if the message is a playlist, then it may. I also noticed that the volume did not return to the previous level. It seemed like it cleared the playlist, adjusted the volume and played the announce.was file and that was it (perhaps not in that order).

                            Originally Posted by gerlin
                            I may need some help getting my system back up and working with V1.0.0.50 (or I am going to need to restore/roll vback my HS system). I put back the old dll and a copy of the "./html/sonoscontroller" I had saved and it does speak the messages, though it does not switch back to the original source after it is done. Are there other files that were updated (I used the beta installer) that I need to roll back?
                            Originally Posted by dcorsus
                            I would go back to .51 which should not affect the hs.speakex functions. Apart from the DLL, see no other change required except that the installer/uninstaller might get a headache if you only overwrite the DLL. If you don't have the .51 installer files, I can email them when I'm home tonight. Not sure why it isn't switching back unless the original state was not correct to start with or maybe you changed something to the event itself?
                            As I mentioned I went back to 50, since it what I have. I do not have 51. Also keep in mind that my 50 was installed by just copying the dll and help files. I put in a few of the versions you sent me this way, so my installer mat have been confused already. I do not believe I changed anything in the event. For testing I would simply call my 'SonosSpeak" script directly. This script puts a wrapper on the the basic SpeakEx command that allows me a little more fine grained operation. The following is what it is doing, though by the time it is done it is just calling SpeakEx:

                            USAGE: sonosSpeak.pl("main","F|M|Say Hello")

                            I look at the first param whic can be a F, B, or A. All I am doing is using this to set the zone to speak to as the family room, bedroom or All. This sets the numeric zone ID I pass to SpeakEx. The second param is either M or F, this allows the event to speak in either a male or female voice (I wonder is this is causing any issues?). This "wraps" the text in tags as follows:

                            <voice required='Name=VW Kate 16k'>$text</voice>
                            or
                            <voice required='Name=VW Paul 16k'>$text</voice>

                            The other "thing" the script does is if the text is to be spoken in the Family room, it checks if Sonos is playing for that zone. If it is not, it switches the receiver to the correct input before the message and back to "tv" after.

                            This has me thinking a little, as I recall I heard quite a bit of extra clicking from my receiver (it does that when switching inputs). I am using the state of the family Sonos zone to automatically switch the receiver. When it is playing it switches the receiver to the Sonos input, when stopped or paused it switches it back to TV.

                            So, if Sonos was playing and got a "stop" or "pause" due to the switch to the announce.wav, it would switch back to TV, then when the message started it would switch back to Sonos, when the message was done the Sonos stop would switch back to TV. Perhaps this is why I lost the beginning of the message, though I would have to test to be sure. I added the extra "switches" in my script, since the line-input switch does not seem to do any stop and start events.

                            I realize this last part (regarding my script) is rather confusing. If you think any of it is relevant and you want better (less confusing) details of what I am doing, just let me know.

                            Originally Posted by dcorsus
                            Sorry for the issues
                            Don't be, this is a beta and we can't step forward without the occasional step back.

                            Hopefully this was not too much information.

                            I plan on rewriting my sonosSpeak in VB (instead of perl), so it cwould make sense to anyone other than myself. If you think this comes down to something I am doing in the script, I will do this sooner than later so you can have a look.

                            Lou
                            Last edited by gerlin; February 7, 2011, 05:45 PM.

                            Comment


                              #29
                              New beta v.55 posted

                              Changes to V1.0.0.55:
                              • Fix to restore Queue after announcement (new implementation) is over
                              • Store shuffle/repeat state before announcement and restore after announcement. When repeat is on, the announcement queue plays indefinitely
                              • Fixed a problems playing MP3 files as part of an announcement. Sonos is doing some weird stuff here as it refuses to play a perfectly good mp3 file, unless I trick Sonos that this is a MP3-Radio-service. I'm anticipating future issues with other file types unfortunately (FLAC....). .WAV and .MP3 files should be OK.
                              • Made some changes to prevent the plug-in from sending stop events when the announcement ends to avoid those who have triggers to turn amps off to get things messed up
                              • Made the Speakerproxy behavior (speak to file and play file versus use audio-input) configurable. You can now find a flag in the configuration page to "Speak to File". If set to true, you will have the new behavior which require no audio connection between HS PC and Sonos Player. If you had already changed your scripts to use the $SONOSFILE$ prefix, this is still supported, I did remove the text from the help file.

                              Comment


                                #30
                                Originally posted by gerlin View Post

                                <voice required='Name=VW Kate 16k'>$text</voice>
                                or
                                <voice required='Name=VW Paul 16k'>$text</voice>


                                So, if Sonos was playing and got a "stop" or "pause" due to the switch to the announce.wav, it would switch back to TV, then when the message started it would switch back to Sonos, when the message was done the Sonos stop would switch back to TV. Perhaps this is why I lost the beginning of the message, though I would have to test to be sure. I added the extra "switches" in my script, since the line-input switch does not seem to do any stop and start events.
                                Lou, just posted v.55. It hopefully takes care of the stop event issues and the behavior (speak to file or audio-input) is now configurable.

                                On the use of different voice, not sure how you scripted this. Do you first set the default voice, then do a speak command? The speakex command does not allow to pass voice parameter so I can't quite get your comment

                                Cheers,

                                Dirk

                                Comment

                                Working...
                                X