Announcement

Collapse
No announcement yet.

'Speak Something' ... someone please put me out of my misery

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

  • #16
    Dirk,

    I have checked the 6 entries, they come in three pairs (privé-1xUDP and 1xTCP, openbaar 1xUDP and 1x TCP, domein 1xUDP and 1xTCP) all with all ports enabled. I do believe these have been generated long time ago automatically with activating the plugin. Gues the private one is the only one used for the plugin though.
    I have changed it and reduced it to two rules only (all, private, public and domain) and restarted the plugin, just to be sure...
    I wonder if this could be causing issues as the endresult of the rules should be the same, either all or per subselection Private, Public or Domain (useless here though). Guess I will check back on this in 10 days.

    Thanks,
    Wim
    -- Wim

    Plugins:RFXCOM, HSTouch Server, Squeezebox, BLGData, Restart, Jon00's Perfmon and Network monitor, WeatherXML, BLBackup, TenScripting, BC4, Pushover, PHLocation, JowiHue, Zwave, Sonos
    650 devices ---- 336 events ----- 40 scripts

    Comment


    • #17
      Originally posted by w.vuyk View Post
      Dirk,

      I have checked the 6 entries, they come in three pairs (privé-1xUDP and 1xTCP, openbaar 1xUDP and 1x TCP, domein 1xUDP and 1xTCP) all with all ports enabled. I do believe these have been generated long time ago automatically with activating the plugin. Gues the private one is the only one used for the plugin though.
      I have changed it and reduced it to two rules only (all, private, public and domain) and restarted the plugin, just to be sure...
      I wonder if this could be causing issues as the endresult of the rules should be the same, either all or per subselection Private, Public or Domain (useless here though). Guess I will check back on this in 10 days.

      Thanks,
      Wim
      Wim, settings look kosher, don't think combing it will make a difference unless there is another rule in there somewhere that plays tricks on us. Other thing to do is to turn debug flag on, log to disk on, let is all sit until the symptom occur, then issue a few commands from the PI and from your Sonos controller. Stop logging to disk (important don't skip!), zip and post log file. By the way, do all players go stale or just some?
      I need to study the UPNP protocol a little. The TCP connection in question is for autonomous event TOWARDS the PI, the thing FW don't like too much. I need to check whether I can perhaps periodically send or renew that connection and keep the FW happy, this would solve this issue once and for all. I believe there is also a UPNP way to communicate with the FW itself to open ports but have no clue how that works and that would be a ton of coding, I'm sure. Maybe there is a .NET function for this but that would probably mess up running things on Linux (urrggghh).

      Dirk

      Comment


      • #18
        dcorsus, would scheduling a PI restart periodically get around the FW issue? Or would it just delay the issue for another time?

        Thanks

        Comment


        • #19
          Originally posted by w.vuyk View Post
          I have similar issues here. Once the sonos plufin is running for around 10 or more days, updates of status fail, including speak commands, that do not get executed or get a timeout. All players show no errors. But the status of devices are off sync. I can check this especially on my playbar, which seem to report a old status - TV is on and TV Input should be the status as the sound is going over the playbar, but status show different.
          Restarting the plugin solves the issue, no need to delete the ini file. Status of the playbar in this case shows TV input as it should. I have worked around this by restarting the plugin once every week.

          Wim
          w.vuyk
          Wim, did this issue ever come back?

          I had some time on my hands and tried to break my UPNP subsystem and I learned a few things:

          a/ when I disable and re-enable an Ethernet port, the multicast listener (windows 10) goes dead without any sign. Which means that when devices drop or come onto the network, the PI won't know about it.

          b/ I noticed when I put my laptop (running HS) to sleep and wake it again, the PI starts getting negative responses on renewals (with error 412). After a lot of experimenting and re-reading the UPNP standard, I deduced that when a Sonos player sends an autonomous event and receives a subsequent error (time out, server not reachable ...), it will terminate its "subscription". Translated, it will stop sending events autonomously until registered properly again. I *might* have included some test code from another project that ignored this error 412 as opposed to dropping the device but if the UPNP debug logging was set to "errors only", I believe there should have been log entries.

          I have posted version .37 in the beta section of the updater with some, what I hope to be, robustness improvements for the above items. If you still have issues, make sure you have your debug levels for PI and UPNP set to error-only or higher, you will see the renewal errors if any.

          I have been having issues with my network of late (son is back home, big surprise), for instance this morning around 5am, I picked up renewal errors on 3 different devices running my PI and they all picked up issues. Not sure why, but I hope one of the newer versions of Sonos SW didn't include some time-planned restart, perhaps one or some of my WAPs are periodically restarting or something else going on.

          So while I'm on the hunt for my network issue, if you still have issues, try out v.37.

          As a last note, I included an audit routine for the multicast listener, which kicks the listener if nothing is received within 30 minutes. If you have devices on your network, there absolutely will be traffic. There is a second (TCP) listener, this one is for these autonomous events. I haven't found a way to make that socket go dead, but if it does, I haven't found a way to detect that. It is this port that (in my opinion) gets blocked by FWs if not configured properly and therefore you receive no more updates. Doing renewals doesn't fix that! While I'm writtng this, I have an idea, perhaps I can send a command to a player which requires the player to generate an autonomous event. If not received within x-seconds, perhaps I should assume the TCP listener port dead (sorry for all the details but some of you like them :-).

          Dirk

          Comment


          • #20
            Originally posted by dcorsus View Post
            (sorry for all the details but some of you like them :-)
            Why watch TV or read a book when there is HomeSeer forum to entertain, and educate

            Comment


            • #21
              Originally posted by dcorsus View Post

              w.vuyk
              Wim, did this issue ever come back?

              I had some time on my hands and tried to break my UPNP subsystem and I learned a few things:

              Dirk
              Dirk,

              I had this issue come back once after the messages exchanged. But I then found out something I never thought of earlier.
              Because of historical (and being lazy) reasons I moved my HS3 installation to another disk in the past to free C:\ drive space. And I created a simlink to emulate HS3 still bing on the same disk location. This saved me of editing all those scripts I have running on the machine.

              So when I was ready to report thie issue back to you, I realised the simlink and checked my firewall rules. The path to the Sonos plugin was indeed also pointing to the c: drive.
              So I decided to adjust this path to its current location on the D:\ drive. And decided to check in again if nothing changed with this setup.

              But since then I never left the machine running for 10 days in a row, becuase I was doing to much work on my own plugin. When I think my updates are ok, The production becomes victim of the first major test So lately the average period of running HS3 and Sonos is shorter....

              A few days ago I noticed errors again coming from the plugin, but did not report yet as I am now mind focussed on the new version of my plugin ofcourse....
              Not sure if they are related though as this is a code 503 coming back. But guess what - this was with the system running for a longer period, but it will take some time as new updates for windows were enforced after that....

              okt-14 05:01:42 Sonos Error Error in Adding VirtualLineIn Call Back for zoneplayer = Slaapkamer. Error=Error in MyUPnPService.AddCallback while sending URL = http://192.168.1.9:1400/MediaRendere...alLineIn/Event to = http://192.168.1.9:1400/MediaRendere...alLineIn/Event with error = De externe server heeft een fout geretourneerd: (503) Server is niet beschikbaar.
              okt-13 23:13:11 Sonos Error Error in Adding VirtualLineIn Call Back for zoneplayer = Zolder. Error=Error in MyUPnPService.AddCallback while sending URL = http://192.168.1.34:1400/MediaRender...alLineIn/Event to = http://192.168.1.34:1400/MediaRender...alLineIn/Event with error = De externe server heeft een fout geretourneerd: (503) Server is niet beschikbaar.
              I will install the V.37 and keep an eye on it here

              Thanks!

              Wim


              -- Wim

              Plugins:RFXCOM, HSTouch Server, Squeezebox, BLGData, Restart, Jon00's Perfmon and Network monitor, WeatherXML, BLBackup, TenScripting, BC4, Pushover, PHLocation, JowiHue, Zwave, Sonos
              650 devices ---- 336 events ----- 40 scripts

              Comment

              Working...
              X