Originally posted by dcorsus
View Post
Announcement
Collapse
No announcement yet.
Starting SONOS plugin causes iOS Client to be slow
Collapse
X
-
_______________________________________________
HS3 : HSpro (3.0.0.460) on Win2012 (vm on ESXi)
Plugins: HSTouch, UPBSpud, Kinect, Nest, IFTTT, DirecTV, EasyTrigger, Imperihome, Zwave, RFXcom, UltraMon3, UltraWeatherBug3, UltraGCIR3, UltraLog3, UltraPioneer, PHLocation, Pushover, Pushalot, MCSSPrinklers S, JowiHue
Jon00 Plugins: Bluetooth Proximity, Performance Monitor, DB Chart, Links
-
Originally posted by jlrichar View PostYes. I swipe closed the HSTouch, and disabled the HSTouch server. I tested in between. With the SONOS plugin enabled, it did not matter what I did with HSTouch--the iOS client was slow. When I disable the SONOS client, it does not matter if I have either or both HSTouch client/Server running--the iOS client is fast.
One more thing to try is to set the UPNP logging level to events and see if there is some flooding going on.
Dirk
Comment
-
Originally posted by jlrichar View PostYes. I swipe closed the HSTouch, and disabled the HSTouch server. I tested in between. With the SONOS plugin enabled, it did not matter what I did with HSTouch--the iOS client was slow. When I disable the SONOS client, it does not matter if I have either or both HSTouch client/Server running--the iOS client is fast.
Dirk
Comment
-
Originally posted by dcorsus View Posthave no clue what might be going on. I'm still on 6.1 will upgrade today.
One more thing to try is to set the UPNP logging level to events and see if there is some flooding going on.
Dirk
Code:Jan-18 9:39:58 PM Sonos MySSDP.TreatNotficationQueue is processing Notification = NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http://192.168.xxx.xxx:80/description.xml SERVER: FreeRTOS/7.4.2 UPnP/1.0 IpBridge/1.10.0 NTS: ssdp:alive hue-bridgeid: 001788FFFE1739C2 NT: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-0017881739c2 RECEIVEEP:192.168.xxx.xxx:1900 Jan-18 9:39:58 PM Sonos MySSDP.TreatNotficationQueue is processing Notification = NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http://192.168.xxx.xxx:80/description.xml SERVER: FreeRTOS/7.4.2 UPnP/1.0 IpBridge/1.10.0 NTS: ssdp:alive hue-bridgeid: 001788FFFE1739C2 NT: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-0017881739c2 RECEIVEEP:192.168.xxx.xxx:1900 Jan-18 9:39:58 PM Sonos MySSDP.TreatNotficationQueue is processing Notification = NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http://192.168.xxx.xxx:80/description.xml SERVER: FreeRTOS/7.4.2 UPnP/1.0 IpBridge/1.10.0 NTS: ssdp:alive hue-bridgeid: 001788FFFE1739C2 NT: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-0017881739c2 RECEIVEEP:192.168.xxx.xxx:1900 Jan-18 9:39:58 PM Sonos MySSDP.TreatNotficationQueue is processing Notification = NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http://192.168.xxx.xxx:80/description.xml SERVER: FreeRTOS/7.4.2 UPnP/1.0 IpBridge/1.10.0 NTS: ssdp:alive hue-bridgeid: 001788FFFE1739C2 NT: uuid:2f402f80-da50-11e1-9b23-0017881739c2 USN: uuid:2f402f80-da50-11e1-9b23-0017881739c2 RECEIVEEP:192.168.xxx.xxx:1900 Jan-18 9:39:58 PM Sonos MySSDP.TreatNotficationQueue is processing Notification = NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http://192.168.xxx.xxx:80/description.xml SERVER: FreeRTOS/7.4.2 UPnP/1.0 IpBridge/1.10.0 NTS: ssdp:alive hue-bridgeid: 001788FFFE1739C2 NT: uuid:2f402f80-da50-11e1-9b23-0017881739c2 USN: uuid:2f402f80-da50-11e1-9b23-0017881739c2 RECEIVEEP:192.168.xxx.xxx:1900 Jan-18 9:39:58 PM Sonos MySSDP.TreatNotficationQueue is processing Notification = NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http://192.168.xxx.xxx:80/description.xml SERVER: FreeRTOS/7.4.2 UPnP/1.0 IpBridge/1.10.0 NTS: ssdp:alive hue-bridgeid: 001788FFFE1739C2 NT: uuid:2f402f80-da50-11e1-9b23-0017881739c2 USN: uuid:2f402f80-da50-11e1-9b23-0017881739c2 RECEIVEEP:192.168.xxx.xxx:1900
_______________________________________________
HS3 : HSpro (3.0.0.460) on Win2012 (vm on ESXi)
Plugins: HSTouch, UPBSpud, Kinect, Nest, IFTTT, DirecTV, EasyTrigger, Imperihome, Zwave, RFXcom, UltraMon3, UltraWeatherBug3, UltraGCIR3, UltraLog3, UltraPioneer, PHLocation, Pushover, Pushalot, MCSSPrinklers S, JowiHue
Jon00 Plugins: Bluetooth Proximity, Performance Monitor, DB Chart, Links
Comment
-
Originally posted by jlrichar View PostI am on the beta 3.1.0.11. After enabling events and errors upnp logging it seems to be a metric ton of these in the log:
Code:Jan-18 9:39:58 PM Sonos MySSDP.TreatNotficationQueue is processing Notification = NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http://192.168.xxx.xxx:80/description.xml SERVER: FreeRTOS/7.4.2 UPnP/1.0 IpBridge/1.10.0 NTS: ssdp:alive hue-bridgeid: 001788FFFE1739C2 NT: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-0017881739c2 RECEIVEEP:192.168.xxx.xxx:1900 Jan-18 9:39:58 PM Sonos MySSDP.TreatNotficationQueue is processing Notification = NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http://192.168.xxx.xxx:80/description.xml SERVER: FreeRTOS/7.4.2 UPnP/1.0 IpBridge/1.10.0 NTS: ssdp:alive hue-bridgeid: 001788FFFE1739C2 NT: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-0017881739c2 RECEIVEEP:192.168.xxx.xxx:1900 Jan-18 9:39:58 PM Sonos MySSDP.TreatNotficationQueue is processing Notification = NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http://192.168.xxx.xxx:80/description.xml SERVER: FreeRTOS/7.4.2 UPnP/1.0 IpBridge/1.10.0 NTS: ssdp:alive hue-bridgeid: 001788FFFE1739C2 NT: urn:schemas-upnp-org:device:basic:1 USN: uuid:2f402f80-da50-11e1-9b23-0017881739c2 RECEIVEEP:192.168.xxx.xxx:1900 Jan-18 9:39:58 PM Sonos MySSDP.TreatNotficationQueue is processing Notification = NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http://192.168.xxx.xxx:80/description.xml SERVER: FreeRTOS/7.4.2 UPnP/1.0 IpBridge/1.10.0 NTS: ssdp:alive hue-bridgeid: 001788FFFE1739C2 NT: uuid:2f402f80-da50-11e1-9b23-0017881739c2 USN: uuid:2f402f80-da50-11e1-9b23-0017881739c2 RECEIVEEP:192.168.xxx.xxx:1900 Jan-18 9:39:58 PM Sonos MySSDP.TreatNotficationQueue is processing Notification = NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http://192.168.xxx.xxx:80/description.xml SERVER: FreeRTOS/7.4.2 UPnP/1.0 IpBridge/1.10.0 NTS: ssdp:alive hue-bridgeid: 001788FFFE1739C2 NT: uuid:2f402f80-da50-11e1-9b23-0017881739c2 USN: uuid:2f402f80-da50-11e1-9b23-0017881739c2 RECEIVEEP:192.168.xxx.xxx:1900 Jan-18 9:39:58 PM Sonos MySSDP.TreatNotficationQueue is processing Notification = NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=100 LOCATION: http://192.168.xxx.xxx:80/description.xml SERVER: FreeRTOS/7.4.2 UPnP/1.0 IpBridge/1.10.0 NTS: ssdp:alive hue-bridgeid: 001788FFFE1739C2 NT: uuid:2f402f80-da50-11e1-9b23-0017881739c2 USN: uuid:2f402f80-da50-11e1-9b23-0017881739c2 RECEIVEEP:192.168.xxx.xxx:1900
SSDP is really chatty so this doesn't necessarily mean anything.
If you take the HUE bridge off-line, do you still see the sluggishness?
Dirk
Comment
-
Originally posted by dcorsus View PostI tried some here, don't see any issue.
SSDP is really chatty so this doesn't necessarily mean anything.
If you take the HUE bridge off-line, do you still see the sluggishness?
Dirk
Any further ideas what I can test?_______________________________________________
HS3 : HSpro (3.0.0.460) on Win2012 (vm on ESXi)
Plugins: HSTouch, UPBSpud, Kinect, Nest, IFTTT, DirecTV, EasyTrigger, Imperihome, Zwave, RFXcom, UltraMon3, UltraWeatherBug3, UltraGCIR3, UltraLog3, UltraPioneer, PHLocation, Pushover, Pushalot, MCSSPrinklers S, JowiHue
Jon00 Plugins: Bluetooth Proximity, Performance Monitor, DB Chart, Links
Comment
-
Originally posted by jlrichar View PostI do have two network ports active with two different IP addresses on the local subnet on the machine running the plugin. Do you think that would cause an issue? I'm trying to think of how my setup could be unique.
Any further ideas what I can test?
So the only thing I can think off is that during discovery which is multicasted, things go wrong, just can't think of a reason why the PI would cause it. The PI only broadcasts at start-up one message and that's it, after that it goes into listening mode.
I could look deeper at the UPNP stuff, if you let it collect for lets say 5 min. Use the "log to disk" option, which will overwrite any existing log file each time you turn it on (so it doesn't append!!). So go to the config page, turn disk logging on, regular logging on, UPNP level to verbose, wait 5 min while doing some stuff on your iOS client, turn disk logging off, compress file, upload. I noted you masked out the IP addresses, these are private addresses, no use to a hacker (or can be discovered in minutes), but if you feel uncomfortable, email me the file. If you "mask" the IP addresses the log is useless.
If you are good with wireshark, you could try to trace the windows client or IOS client and see what kind of traffic (might) flood. Sonos does build up its own wireless forwarding (STP) view, if lets say it receives messages that makes him think it needs to reconfigure (all the time) that might explain why it is sluggish, still can't think why the PI would cause it. If you run the windows client, is this a client on your HS PC or a client on a windows phone? If this client is on a windows machine, we can definitely trace it with wireshark. How many players do you have? Are they wired or wireless? If the latter, do you use a Sons bridge? If so ever tried to connect the bridge or players differently? If you have 2 ethernet ports, do you use different subnets or the same? Do you have forwarding active between the ports, more importantly, helpers for broadcast or multicast forwarding?
Dirk
Comment
-
Originally posted by dcorsus View PostDisconnect one port and see if that makes a difference. I'm out of ideas to be honest given that the PI doesn't even know of the existence of a Sonos controller and not communicate with them. Moreover, there is no polling of any sort in the PI so the way it works is that, the PI after discovering a player, "signs up" for events, so it is the player itself that generates traffic (events).
So the only thing I can think off is that during discovery which is multicasted, things go wrong, just can't think of a reason why the PI would cause it. The PI only broadcasts at start-up one message and that's it, after that it goes into listening mode.
I could look deeper at the UPNP stuff, if you let it collect for lets say 5 min. Use the "log to disk" option, which will overwrite any existing log file each time you turn it on (so it doesn't append!!). So go to the config page, turn disk logging on, regular logging on, UPNP level to verbose, wait 5 min while doing some stuff on your iOS client, turn disk logging off, compress file, upload. I noted you masked out the IP addresses, these are private addresses, no use to a hacker (or can be discovered in minutes), but if you feel uncomfortable, email me the file. If you "mask" the IP addresses the log is useless.
If you are good with wireshark, you could try to trace the windows client or IOS client and see what kind of traffic (might) flood. Sonos does build up its own wireless forwarding (STP) view, if lets say it receives messages that makes him think it needs to reconfigure (all the time) that might explain why it is sluggish, still can't think why the PI would cause it. If you run the windows client, is this a client on your HS PC or a client on a windows phone? If this client is on a windows machine, we can definitely trace it with wireshark. How many players do you have? Are they wired or wireless? If the latter, do you use a Sons bridge? If so ever tried to connect the bridge or players differently? If you have 2 ethernet ports, do you use different subnets or the same? Do you have forwarding active between the ports, more importantly, helpers for broadcast or multicast forwarding?
Dirk
I will try to capture some log to disk data for you to look at. My windows client is on another windows desktop machine on the network. Both of my zp's are wired. I do not have any sonos wireless turned on. Unfortunately from a SONOS perspective it is a very simple setup. Just two wired players. No SONOS speakers. I have no experience with wireshark--but I can take a look at that too. I originally setup two ports on this machine so that if the main port gets saturated it does not interfere with remote plugins trying to communicate with HS. Both ports are on the same subnet, and both could be used by the OS, though it prioritizes the one I made first. The second one is the one I use for remote plugins and is the IP I point them to._______________________________________________
HS3 : HSpro (3.0.0.460) on Win2012 (vm on ESXi)
Plugins: HSTouch, UPBSpud, Kinect, Nest, IFTTT, DirecTV, EasyTrigger, Imperihome, Zwave, RFXcom, UltraMon3, UltraWeatherBug3, UltraGCIR3, UltraLog3, UltraPioneer, PHLocation, Pushover, Pushalot, MCSSPrinklers S, JowiHue
Jon00 Plugins: Bluetooth Proximity, Performance Monitor, DB Chart, Links
Comment
-
Originally posted by jlrichar View PostI will try to capture some log to disk data for you to look at. My windows client is on another windows desktop machine on the network. Both of my zp's are wired. I do not have any sonos wireless turned on. Unfortunately from a SONOS perspective it is a very simple setup. Just two wired players. No SONOS speakers. I have no experience with wireshark--but I can take a look at that too. I originally setup two ports on this machine so that if the main port gets saturated it does not interfere with remote plugins trying to communicate with HS. Both ports are on the same subnet, and both could be used by the OS, though it prioritizes the one I made first. The second one is the one I use for remote plugins and is the IP I point them to.
Are both ports connected to the same network or different physical segments of your network?
If you say remote PI, what PIs are your running remote? Is this on another PC at home or through a tunnel with another home?
If different (parts) of your network, do you have bridging or forwarding enabled between the 2 ports?
Dirk
Comment
-
Originally posted by dcorsus View PostHave you tried disconnecting one port and see what happens?
Are both ports connected to the same network or different physical segments of your network?
If you say remote PI, what PIs are your running remote? Is this on another PC at home or through a tunnel with another home?
If different (parts) of your network, do you have bridging or forwarding enabled between the 2 ports?
Dirk_______________________________________________
HS3 : HSpro (3.0.0.460) on Win2012 (vm on ESXi)
Plugins: HSTouch, UPBSpud, Kinect, Nest, IFTTT, DirecTV, EasyTrigger, Imperihome, Zwave, RFXcom, UltraMon3, UltraWeatherBug3, UltraGCIR3, UltraLog3, UltraPioneer, PHLocation, Pushover, Pushalot, MCSSPrinklers S, JowiHue
Jon00 Plugins: Bluetooth Proximity, Performance Monitor, DB Chart, Links
Comment
-
This is fixed. It turns out I needed to add hspi_sonos.exe to the firewall because it dynamically allocates some ports for control. After doing so the iOS and windows clients were just as responsive with and without the plugin running._______________________________________________
HS3 : HSpro (3.0.0.460) on Win2012 (vm on ESXi)
Plugins: HSTouch, UPBSpud, Kinect, Nest, IFTTT, DirecTV, EasyTrigger, Imperihome, Zwave, RFXcom, UltraMon3, UltraWeatherBug3, UltraGCIR3, UltraLog3, UltraPioneer, PHLocation, Pushover, Pushalot, MCSSPrinklers S, JowiHue
Jon00 Plugins: Bluetooth Proximity, Performance Monitor, DB Chart, Links
Comment
Comment