Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[yinmeout]

I've had a full on week this week and so I don't know when it happened - but my Sonos devices are no longer showing up as Zones.
I've restarted everything (servers clients and sonos devices) and left the firewalls off just as a sanity check.
Playback works fine on the Sonos devices and I can see them. Media Center seems to be working just fine. - MC finds other devices (TV's) - just not the Sonos devices anymore!

Anyone else having this issue or know how to start digging into causes?

I took a look at the SSDP log in Media Network - but beyond seeing the multicast addresses from the relevant source IP's and M-SEARCH / NOTIFY frames, I don't know how to interpret that data very well.

It's like completely killed my music ! :-(

[JimH]

Power everything down and back up.  Computers, Sonos, routers, everything.

[yinmeout]

Thanks Jim - I did exactly as directed and I am sorry to say I am still no better off.
JRiver does not see them. . . but does see other devices responding to SSDP.

It's the same experience on two separate computers both with JRiver installed. One is a standalone client the other is set up to be a server. Neither can see Sonos devices anymore. When I enable Media Network on the client (which is normally not enabled as it's enabled on the 'server') it also does not find the Sonos devices.
On the same computer, the Sonos devices are all visible in the Sonos app and appear in explorer under "This PC" (Win8.1). When I right click them, their details are correct (they have reservations in DHCP on the router.) Both via Wired and Wireless Connections. I can see the correct IP addresses flicking round in the SSDP Activity Log. . .

So I am not sure what to say / do to resolve this - a long week and I certainly did not change anything I know of. . .

I am sure this is unrelated but, the last time I used the system - I added a port rule into my router so that I could access the system over the internet on my iPad via JRemote - which worked perfectly.
I could see all the zones - but obviously chose the local player - which worked faultlessly.

[AndrewFG]

Check that all your PCs and the Sonos players all have IP addresses on the same subnet.

Normally if your router has a DHCP server, and the players and PCs are set to use DHCP then the router will ensure that all devices are on the same subnet, and it will route packets between all devices. Whereas if one or other has an IP address on a different subnet, then it is likely that the router will not route packets properly between them all.

[yinmeout]

Hi Andrew,

Thanks for the pointer. They are all on the same subnet - unfortunately - I statically configure everything in 20 address octets - so I know the range for wired PC's / Phones / Wireless PC's / Harware Devices / Sonos Devices / Virtual Machines / Servers etc etc.

3    192.168.1.35    MAIN    00:22:4D:4F:BC:BE
4    192.168.1.61    Sonos Bedroom    00:0E:58:58:2B:DC
5    192.168.1.62    sonos Kitchen    00:0E:58:34:A4:6C
6    192.168.1.63    Sonos Main    00:0E:58:24:B5:FE
7    192.168.1.64    Sonos Bedroom 2    00:0E:58:59:56:4A
8    192.168.1.70    HD HomeRun    00:18:DD:21:0A:DE
9    192.168.1.120    SERVER    00:1E:8C:F1:C1:E9
10    192.168.1.122    WDS    00:15:5D:01:78:07
11    192.168.1.123    EXCHANGE    00:15:5D:01:78:44

[AndrewFG]

^

It depends on the router's subnet mask..

If the subnet mask was 255.255.255.0 then the allowed IP range would be 192.168.1.0 to 255 -- so all your devices are on the net.
However if the mask was 255.255.255.192 then the allowed IP range would be 192.168.1.0 to 63 -- so those above 63 would be off net.

But to be fair 255.255.255.0 is the most likely setting..

[yinmeout]

It is 255.255.255.0

[AndrewFG]

Ok. Its not a subnet issue then.

I wonder if it could be something in your router's settings for multicast routing ( http://en.wikipedia.org/wiki/Internet_Group_Management_Protocol ) ??

[yinmeout]

Ok I am starting to get slightly ruffled. . .

I whipped out the hard disk of a spare laptop - and put in a spare disk and installed the thing from scratch - (from a deployment image, so 10 mins work).
I then wire connected a Play 5 and the rebuilt laptop to the same switch.
The laptop finds all the Sonos devices and shows them in Windows Explorer. ( not just the one on that switch. )
I installed J River and then enabled media network and allowed it to do its firewall thing.
It does not see the Sonos device on that switch or any other Sonos Devices, in the 'Playing Now' area.

( note: that sounds blaming - I am not blaming, if there were a systemic issue, I guess the forum would be flooded! )

Is there some logging I can enable to take a closer look as to what might be going on?
It's very hard to troubleshoot further without a log or a reference working system - sadly.

To your point Andrew - there are four switches between me and the Router - the Router is purely an Internet Gateway - everything else is wired into switches with Cat 5.
Even the Play 5's are wired not wireless. I do use wireless but only for things like phones and Ipads which do not do any real data transfer.

The switches can't be duff otherwise I could not be writing or posting this response - this machine is on the last switch in the chain, but the sonos devices are connected along the way to almost every one and as I say they are seen fine. It's like Sonos have done some update that screws this up somehow. . .

Cheers.

[JimH]

Are you running 20.0.17?
http://yabb.jriver.com/interact/index.php?topic=91984.0

[yinmeout]

Hi Jim,

The test was done with MC 20 yes - but the main rig is still on MC 19 - no time to upgrade and I have al least a man month invested in that library - so super cautious about changes.

Regards
Anthony

[AndrewFG]

The laptop finds all the Sonos devices and shows them in Windows Explorer. ( not just the one on that switch. )
I installed J River and then enabled media network and allowed it to do its firewall thing.
It does not see the Sonos device on that switch or any other Sonos Devices, in the 'Playing Now' area.

Just for the avoidance of doubt: Are you saying that on the same PC the Sonos units do appear in Windows Network Devices, and they do not appear in MC?

If so, (excuse the obvious question: did you check the gas tank), but do you have MC Options / Media Network / Advanced / DLNA Controller -- turned on?

If not, then I am flummoxed...

EDIT: regarding your question about logging: in MC left navigator bar select Services & Plugins / Media Network..

[yinmeout]

For the avoidance of doubt,

Yes that is exactly what I am saying - they DO appear in Windows Network Devices and NOT in MC.
And yes All the DNLA options are checked - inc DNLA controller (the important one in this case).

Ok so I can see the Multicast packets flowing the network as per previous messages.

Is there some other setting that determines whether the discovered DNAL devices appear as zones or are somehow hidden> ??

[yinmeout]

For the avoidance of doubt,

Yes that is exactly what I am saying - they DO appear in Windows Network Devices and NOT in MC.
And yes All the DNLA options are checked - inc DNLA controller (the important one in this case).

Ok so I can see the Multicast packets flowing the network as per previous messages.

Is there some other setting that determines whether the discovered DNAL devices appear as zones or are somehow hidden> ??

[yinmeout]

<edit> removed irrelevance. <edit>

So UPD port 1900 is open and a process is listening to it
Netstat -ano (for those who are interested later)

 UDP    0.0.0.0:1900           *:*                                    2144
Media Center 19.exe           2144 Console                    1     55,612 K

Process id's match.
Wireshark Trace reveals that the Sonos devices are broadcasting Muticast SSDP info against port 1900 I am tracing the same interface as MC is running against - i.e. this machine.
 - it should be working !

I can literally see the packets arriving in the sniffer - the ones from the DNLA TV arrive and pop the TV appears immediately in the Zones list
The ones from the zonos IP's arrive and zip - no new renders in the zones.

Can I have a checked version of MC please - pretty please

[AndrewFG]

Your reports seem to indicate that MC might be working Ok for the "discovery" phase of the UPnP initialization processes. So it could be that MC is encountering an error in a later stage -- perhaps in the "description" or "command" phase of the UPnP initialization processes.

Go to MC / Help / Logging / check Enable logging function, then stop and restart MC, and wait for it to go through its discovery phase. Then open the log file and look for any GET requests from MC targeted at any of the Sonos devices. If there are no GET requests, then there is probably indeed something going wrong in the UDP "discovery" phase; whereas if there are some GET requests, then perhaps the log would tell us if something went wrong.

[yinmeout]

Very helpful - thank you so much. Will execute and report.

[yinmeout]

Ok so now were cooking with GAS! as they say over here.
I managed to get it working on another PC - don't ask me how - that is so annoying! I work in IT and I hate it when a root cause is not found or does not expose itself.
So whining over, I took a log off the good machine and compared it to the log from the bad machine - now I think the error is pretty obvious actually.

EDIT out incorrect assumptions.

Here is the log . . http://1drv.ms/1sWa4W1

It does seem like we are 'hearing' the info from the Sonos devices after all but they are not appearing
0368656: 4056: Sharing Plugins: CHTTPListenerWorker::HandleRequest: UDP: 192.168.1.64: NOTIFY: http://239.255.255.250:1900*

the are 192.168.1.61 - 2 - 3 and 4

[AndrewFG]

0031282: 9536: Reader: CWinINetReader::Open: Start
0031282: 9536: Reader: CWinINetReader::Open: Opening http://192.168.1.63:1400/xml/device_description.xml
0031282: 11220: Reader: CWinINetReader::Thread: Start
0031282: 11220: Reader: CWinINetReader::Connect: Start
0031282: 11220: Reader: CWinINetReader::Connect: Finish (0 ms)
0031282: 11220: Reader: CWinINetReader::DownloadFromHTTPURL: Start
0031297: 11220: Reader: CWinINetReader::DownloadFromHTTPURL: Success
0031297: 11220: Reader: CWinINetReader::DownloadFromHTTPURL: Finish (15 ms)
0031297: 11220: Reader: CWinINetReader::Thread: Finish (15 ms)
0031297: 9536: Reader: CWinINetReader::Open: Finish (15 ms)
0031297: 9536: Reader: CWinINetReader::Read: InternetReadFile returned true with zero bytes read: EOF
0031297: 9536: Reader: CWinINetReader::Close: Start
0031297: 9536: Reader: CWinINetReader::Close: Finish (0 ms)

It looks like MC is finding the Sonos renderer but when MC tries to load the device description document the Sonos' returns zero bytes. I don't know MC logs that well, this could certainly mean that the Sonos is returning zero data for MC's GET request; but it might possibly mean that there is a firewall blocking the data (although in that case I would be surprised to see a "success" response).

To get a more specific answer you'll need a response from someone at JRiver..

[bob]

What do you see when you open the link in a browser?
http://192.168.1.63:1400/xml/device_description.xml

[yinmeout]

I get this:

1 0 urn:schemas-upnp-org:device:ZonePlayer:1 192.168.1.63 - Sonos CONNECT Sonos, Inc. http://www.sonos.com ZP90 Sonos CONNECT Sonos CONNECT http://www.sonos.com/products/zoneplayers/ZP90 27.2-80271 1.1.16.4-2 00-0E-58-24-B5-FE:F uuid:RINCON_000E5824B5FE01400 0 image/png 48 48 24 /img/icon-ZP90.png 26.0-00000 24.0-0000 5.1 r8: 16.0-7 Living Room CONNECT 1 0x00310001 0x00006172 0x00030021 -1 0.000 0.000 32 32 425 urn:schemas-upnp-org:service:AlarmClock:1 urn:upnp-org:serviceId:AlarmClock /AlarmClock/Control /AlarmClock/Event /xml/AlarmClock1.xml urn:schemas-upnp-org:service:MusicServices:1 urn:upnp-org:serviceId:MusicServices /MusicServices/Control /MusicServices/Event /xml/MusicServices1.xml urn:schemas-upnp-org:service:AudioIn:1 urn:upnp-org:serviceId:AudioIn /AudioIn/Control /AudioIn/Event /xml/AudioIn1.xml urn:schemas-upnp-org:service:DeviceProperties:1 urn:upnp-org:serviceId:DeviceProperties /DeviceProperties/Control /DeviceProperties/Event /xml/DeviceProperties1.xml urn:schemas-upnp-org:service:SystemProperties:1 urn:upnp-org:serviceId:SystemProperties /SystemProperties/Control /SystemProperties/Event /xml/SystemProperties1.xml urn:schemas-upnp-org:service:ZoneGroupTopology:1 urn:upnp-org:serviceId:ZoneGroupTopology /ZoneGroupTopology/Control /ZoneGroupTopology/Event /xml/ZoneGroupTopology1.xml urn:schemas-upnp-org:service:GroupManagement:1 urn:upnp-org:serviceId:GroupManagement /GroupManagement/Control /GroupManagement/Event /xml/GroupManagement1.xml urn:schemas-tencent-com:service:QPlay:1 urn:tencent-com:serviceId:QPlay /QPlay/Control /QPlay/Event /xml/QPlay1.xml urn:schemas-upnp-org:device:MediaServer:1 192.168.1.63 - Sonos CONNECT Media Server Sonos, Inc. http://www.sonos.com ZP90 Sonos CONNECT Media Server Sonos CONNECT http://www.sonos.com/products/zoneplayers/ZP90 uuid:RINCON_000E5824B5FE01400_MS urn:schemas-upnp-org:service:ContentDirectory:1 urn:upnp-org:serviceId:ContentDirectory /MediaServer/ContentDirectory/Control /MediaServer/ContentDirectory/Event /xml/ContentDirectory1.xml urn:schemas-upnp-org:service:ConnectionManager:1 urn:upnp-org:serviceId:ConnectionManager /MediaServer/ConnectionManager/Control /MediaServer/ConnectionManager/Event /xml/ConnectionManager1.xml urn:schemas-upnp-org:device:MediaRenderer:1 Living Room - Sonos CONNECT Media Renderer Sonos, Inc. http://www.sonos.com ZP90 Sonos CONNECT Media Renderer Sonos CONNECT http://www.sonos.com/products/zoneplayers/ZP90 uuid:RINCON_000E5824B5FE01400_MR urn:schemas-upnp-org:service:RenderingControl:1 urn:upnp-org:serviceId:RenderingControl /MediaRenderer/RenderingControl/Control /MediaRenderer/RenderingControl/Event /xml/RenderingControl1.xml urn:schemas-upnp-org:service:ConnectionManager:1 urn:upnp-org:serviceId:ConnectionManager /MediaRenderer/ConnectionManager/Control /MediaRenderer/ConnectionManager/Event /xml/ConnectionManager1.xml urn:schemas-upnp-org:service:AVTransport:1 urn:upnp-org:serviceId:AVTransport /MediaRenderer/AVTransport/Control /MediaRenderer/AVTransport/Event /xml/AVTransport1.xml urn:schemas-sonos-com:service:Queue:1 urn:sonos-com:serviceId:Queue /MediaRenderer/Queue/Control /MediaRenderer/Queue/Event /xml/Queue1.xml urn:schemas-upnp-org:service:GroupRenderingControl:1 urn:upnp-org:serviceId:GroupRenderingControl /MediaRenderer/GroupRenderingControl/Control /MediaRenderer/GroupRenderingControl/Event /xml/GroupRenderingControl1.xml urn:rhapsody-real-com:device-id-1-0:sonos_1:RINCON_000E5824B5FE01400 QPlay:2 image/png 48 48 24 /img/icon-ZP90.png

Which I am guessing is good

Searching my working and failing logs against this string "CHTTPListenerWorker::HandleRequest:" is showing some marked difference between the working and failing logs that I have.
But as you say - intimate product knowledge needed I think - at this point.

[AndrewFG]

What do you see when you open the link in a browser?

Maybe I am paranoid or perhaps they are just out to get me: a while ago Jim was talking about the Id being a "Sonos killer" .. so are they trying to get even ??

[bob]

Could you look at that link in IE? It should format the xml.
Then post it here again using a code block in the message (the # sign in the tools).
It's a bit tough to read as it...
Off the top though, I don't see anything particularily weird.

[yinmeout]

Code: [Select]

<?xml version="1.0" encoding="UTF-8"?>

-<root xmlns="urn:schemas-upnp-org:device-1-0">


-<specVersion>

<major>1</major>

<minor>0</minor>

</specVersion>


-<device>

<deviceType>urn:schemas-upnp-org:device:ZonePlayer:1</deviceType>

<friendlyName>192.168.1.63 - Sonos CONNECT</friendlyName>

<manufacturer>Sonos, Inc.</manufacturer>

<manufacturerURL>http://www.sonos.com</manufacturerURL>

<modelNumber>ZP90</modelNumber>

<modelDescription>Sonos CONNECT</modelDescription>

<modelName>Sonos CONNECT</modelName>

<modelURL>http://www.sonos.com/products/zoneplayers/ZP90</modelURL>

<softwareVersion>27.2-80271</softwareVersion>

<hardwareVersion>1.1.16.4-2</hardwareVersion>

<serialNum>00-0E-58-24-B5-FE:F</serialNum>

<UDN>uuid:RINCON_000E5824B5FE01400</UDN>


-<iconList>


-<icon>

<id>0</id>

<mimetype>image/png</mimetype>

<width>48</width>

<height>48</height>

<depth>24</depth>

<url>/img/icon-ZP90.png</url>

</icon>

</iconList>

<minCompatibleVersion>26.0-00000</minCompatibleVersion>

<legacyCompatibleVersion>24.0-0000</legacyCompatibleVersion>

<displayVersion>5.1</displayVersion>

<extraVersion>r8: 16.0-7</extraVersion>

<roomName>Living Room</roomName>

<displayName>CONNECT</displayName>

<zoneType>1</zoneType>

<feature1>0x00310001</feature1>

<feature2>0x00006172</feature2>

<feature3>0x00030021</feature3>

<internalSpeakerSize>-1</internalSpeakerSize>

<bassExtension>0.000</bassExtension>

<satGainOffset>0.000</satGainOffset>

<memory>32</memory>

<flash>32</flash>

<ampOnTime>425</ampOnTime>


-<serviceList>


-<service>

<serviceType>urn:schemas-upnp-org:service:AlarmClock:1</serviceType>

<serviceId>urn:upnp-org:serviceId:AlarmClock</serviceId>

<controlURL>/AlarmClock/Control</controlURL>

<eventSubURL>/AlarmClock/Event</eventSubURL>

<SCPDURL>/xml/AlarmClock1.xml</SCPDURL>

</service>


-<service>

<serviceType>urn:schemas-upnp-org:service:MusicServices:1</serviceType>

<serviceId>urn:upnp-org:serviceId:MusicServices</serviceId>

<controlURL>/MusicServices/Control</controlURL>

<eventSubURL>/MusicServices/Event</eventSubURL>

<SCPDURL>/xml/MusicServices1.xml</SCPDURL>

</service>


-<service>

<serviceType>urn:schemas-upnp-org:service:AudioIn:1</serviceType>

<serviceId>urn:upnp-org:serviceId:AudioIn</serviceId>

<controlURL>/AudioIn/Control</controlURL>

<eventSubURL>/AudioIn/Event</eventSubURL>

<SCPDURL>/xml/AudioIn1.xml</SCPDURL>

</service>


-<service>

<serviceType>urn:schemas-upnp-org:service:DeviceProperties:1</serviceType>

<serviceId>urn:upnp-org:serviceId:DeviceProperties</serviceId>

<controlURL>/DeviceProperties/Control</controlURL>

<eventSubURL>/DeviceProperties/Event</eventSubURL>

<SCPDURL>/xml/DeviceProperties1.xml</SCPDURL>

</service>


-<service>

<serviceType>urn:schemas-upnp-org:service:SystemProperties:1</serviceType>

<serviceId>urn:upnp-org:serviceId:SystemProperties</serviceId>

<controlURL>/SystemProperties/Control</controlURL>

<eventSubURL>/SystemProperties/Event</eventSubURL>

<SCPDURL>/xml/SystemProperties1.xml</SCPDURL>

</service>


-<service>

<serviceType>urn:schemas-upnp-org:service:ZoneGroupTopology:1</serviceType>

<serviceId>urn:upnp-org:serviceId:ZoneGroupTopology</serviceId>

<controlURL>/ZoneGroupTopology/Control</controlURL>

<eventSubURL>/ZoneGroupTopology/Event</eventSubURL>

<SCPDURL>/xml/ZoneGroupTopology1.xml</SCPDURL>

</service>


-<service>

<serviceType>urn:schemas-upnp-org:service:GroupManagement:1</serviceType>

<serviceId>urn:upnp-org:serviceId:GroupManagement</serviceId>

<controlURL>/GroupManagement/Control</controlURL>

<eventSubURL>/GroupManagement/Event</eventSubURL>

<SCPDURL>/xml/GroupManagement1.xml</SCPDURL>

</service>


-<service>

<serviceType>urn:schemas-tencent-com:service:QPlay:1</serviceType>

<serviceId>urn:tencent-com:serviceId:QPlay</serviceId>

<controlURL>/QPlay/Control</controlURL>

<eventSubURL>/QPlay/Event</eventSubURL>

<SCPDURL>/xml/QPlay1.xml</SCPDURL>

</service>

</serviceList>


-<deviceList>


-<device>

<deviceType>urn:schemas-upnp-org:device:MediaServer:1</deviceType>

<friendlyName>192.168.1.63 - Sonos CONNECT Media Server</friendlyName>

<manufacturer>Sonos, Inc.</manufacturer>

<manufacturerURL>http://www.sonos.com</manufacturerURL>

<modelNumber>ZP90</modelNumber>

<modelDescription>Sonos CONNECT Media Server</modelDescription>

<modelName>Sonos CONNECT</modelName>

<modelURL>http://www.sonos.com/products/zoneplayers/ZP90</modelURL>

<UDN>uuid:RINCON_000E5824B5FE01400_MS</UDN>


-<serviceList>


-<service>

<serviceType>urn:schemas-upnp-org:service:ContentDirectory:1</serviceType>

<serviceId>urn:upnp-org:serviceId:ContentDirectory</serviceId>

<controlURL>/MediaServer/ContentDirectory/Control</controlURL>

<eventSubURL>/MediaServer/ContentDirectory/Event</eventSubURL>

<SCPDURL>/xml/ContentDirectory1.xml</SCPDURL>

</service>


-<service>

<serviceType>urn:schemas-upnp-org:service:ConnectionManager:1</serviceType>

<serviceId>urn:upnp-org:serviceId:ConnectionManager</serviceId>

<controlURL>/MediaServer/ConnectionManager/Control</controlURL>

<eventSubURL>/MediaServer/ConnectionManager/Event</eventSubURL>

<SCPDURL>/xml/ConnectionManager1.xml</SCPDURL>

</service>

</serviceList>

</device>


-<device>

<deviceType>urn:schemas-upnp-org:device:MediaRenderer:1</deviceType>

<friendlyName>Living Room - Sonos CONNECT Media Renderer</friendlyName>

<manufacturer>Sonos, Inc.</manufacturer>

<manufacturerURL>http://www.sonos.com</manufacturerURL>

<modelNumber>ZP90</modelNumber>

<modelDescription>Sonos CONNECT Media Renderer</modelDescription>

<modelName>Sonos CONNECT</modelName>

<modelURL>http://www.sonos.com/products/zoneplayers/ZP90</modelURL>

<UDN>uuid:RINCON_000E5824B5FE01400_MR</UDN>


-<serviceList>


-<service>

<serviceType>urn:schemas-upnp-org:service:RenderingControl:1</serviceType>

<serviceId>urn:upnp-org:serviceId:RenderingControl</serviceId>

<controlURL>/MediaRenderer/RenderingControl/Control</controlURL>

<eventSubURL>/MediaRenderer/RenderingControl/Event</eventSubURL>

<SCPDURL>/xml/RenderingControl1.xml</SCPDURL>

</service>


-<service>

<serviceType>urn:schemas-upnp-org:service:ConnectionManager:1</serviceType>

<serviceId>urn:upnp-org:serviceId:ConnectionManager</serviceId>

<controlURL>/MediaRenderer/ConnectionManager/Control</controlURL>

<eventSubURL>/MediaRenderer/ConnectionManager/Event</eventSubURL>

<SCPDURL>/xml/ConnectionManager1.xml</SCPDURL>

</service>


-<service>

<serviceType>urn:schemas-upnp-org:service:AVTransport:1</serviceType>

<serviceId>urn:upnp-org:serviceId:AVTransport</serviceId>

<controlURL>/MediaRenderer/AVTransport/Control</controlURL>

<eventSubURL>/MediaRenderer/AVTransport/Event</eventSubURL>

<SCPDURL>/xml/AVTransport1.xml</SCPDURL>

</service>


-<service>

<serviceType>urn:schemas-sonos-com:service:Queue:1</serviceType>

<serviceId>urn:sonos-com:serviceId:Queue</serviceId>

<controlURL>/MediaRenderer/Queue/Control</controlURL>

<eventSubURL>/MediaRenderer/Queue/Event</eventSubURL>

<SCPDURL>/xml/Queue1.xml</SCPDURL>

</service>


-<service>

<serviceType>urn:schemas-upnp-org:service:GroupRenderingControl:1</serviceType>

<serviceId>urn:upnp-org:serviceId:GroupRenderingControl</serviceId>

<controlURL>/MediaRenderer/GroupRenderingControl/Control</controlURL>

<eventSubURL>/MediaRenderer/GroupRenderingControl/Event</eventSubURL>

<SCPDURL>/xml/GroupRenderingControl1.xml</SCPDURL>

</service>

</serviceList>


-<X_Rhapsody-Extension xmlns="http://www.real.com/rhapsody/xmlns/upnp-1-0">

<deviceID>urn:rhapsody-real-com:device-id-1-0:sonos_1:RINCON_000E5824B5FE01400</deviceID>


-<deviceCapabilities>

<interactionPattern type="real-rhapsody-upnp-1-0"/>

</deviceCapabilities>

</X_Rhapsody-Extension>

<qq:X_QPlay_SoftwareCapability xmlns:qq="http://www.tencent.com">QPlay:2</qq:X_QPlay_SoftwareCapability>


-<iconList>


-<icon>

<mimetype>image/png</mimetype>

<width>48</width>

<height>48</height>

<depth>24</depth>

<url>/img/icon-ZP90.png</url>

</icon>

</iconList>

</device>

</deviceList>

</device>

</root>

[yinmeout]

Sorry Bob - hopefully that's better now.

[AndrewFG]

Wow!  

That DDD is certainly pushing the envelope of a legal UPnP document. It is way outside the DLNA guidelines, but it probably is within the UPnP specifications themselves. It is a device with embedded devices within it (this is legal in the UPnP specs, but frankly I never saw such a case in reality). It includes a lot of vendor specific services (which are not illegal, although these ones are wrongly declared within the UPnP namespace rather than a vendor namespace). And it includes a lot of non UPnP xml stuff too.

This is a DDD for a so called UPnP root device. It does include an embedded MediaServer device and also an embedded MediaRenderer device amongst all the other stuff. Nevertheless I think my own CP code would not be able to discover those from within this root device, and I would not be surprised if MC had similar problems. I would be interested to see if Sonos also exposes the individual MediaServer and MediaRenderer devices as separate entities too. If so then an M-SEARCH for MediaRenderers might return cleaner DDD xml than this.

For me, the mystery is not so much why your one MC instance chokes on this, but rather why your other instance of MC seems to still work..

[yinmeout]

I wonder what I can do - thinking - resetting the devices to factory defaults somehow . . .
Otherwise I have around $4k of junk 

[JimH]

You could report what you know to Sonos and tell them we'll provide a license if they would like to try to reproduce the problem.

Think about how the two machines are different.  OS?  Firewall?  Antivirus?  Networking options?

Did you make any recent changes to either PC?

[yinmeout]

The only major difference is that one is a server running 'the universe' and one is an Win8.1 client.

From a core OS perspective - its the same code tree they are built from - but configuration wise there will be some differences certainly.

This only started happening recently and the most recent change I know of was some Windows updates back on patch Tuesday in September.

I might restore the server to last months backup and see if that works. Its days and days of work to rebuild it so there is simply no chance, at the moment of doing that.

Since we already  proved that it's not a networking problem in terms of conversation. My plan now is to take a toothpick to the logs from the working and failing machine - to at least narrow the area. Maybe get a Procmon.exe trace and go through that - I've always found a procmon helpful.

Try to reconfigure Sonos as they recently started supporting wireless (to use wireless) and that would mean I could unplug the Sonos bridge from Ethernet - which is the reason it has all those devices embedded in the config file which is so HUGE - I am guessing.  As I am sure you know Sonos up till very recently used its own wireless network only to communicate internally. But this has changed as I say.

As a last resort I'll go hammer on the closed door that is Sonos - maybe I'll get lucky.

A huge thank you to the folks who stepped up and offered advice upon this problem - if I unearth anything more of use - I'll post back here.

[bob]

Wow!  

That DDD is certainly pushing the envelope of a legal UPnP document. It is way outside the DLNA guidelines, but it probably is within the UPnP specifications themselves. It is a device with embedded devices within it (this is legal in the UPnP specs, but frankly I never saw such a case in reality). It includes a lot of vendor specific services (which are not illegal, although these ones are wrongly declared within the UPnP namespace rather than a vendor namespace). And it includes a lot of non UPnP xml stuff too.

This is a DDD for a so called UPnP root device. It does include an embedded MediaServer device and also an embedded MediaRenderer device amongst all the other stuff. Nevertheless I think my own CP code would not be able to discover those from within this root device, and I would not be surprised if MC had similar problems. I would be interested to see if Sonos also exposes the individual MediaServer and MediaRenderer devices as separate entities too. If so then an M-SEARCH for MediaRenderers might return cleaner DDD xml than this.

For me, the mystery is not so much why your one MC instance chokes on this, but rather why your other instance of MC seems to still work..

It's an interesting comparison with the Raumfeld devices which work in a similar way.
Raumfeld however splits the functions into different root devices.
There's a config device, the wifi configuration device, a speaker device and a media server device as well as a DLNA renderer.
Seems more sensible and plays nice with MC.

[AndrewFG]

There's a config device, the wifi configuration device, a speaker device and a media server device as well as a DLNA renderer.
Seems more sensible and plays nice with MC.

Yup. That is the way I would do it too.

[AndrewFG]

My plan now is to take a toothpick to the logs from the working and failing machine - to at least narrow the area. Maybe get a Procmon.exe trace and go through that - I've always found a procmon helpful.

I have written an analytics tool. (Bob know what I am referring to). I will send you a PM.

[AndrewFG]

I tested the Sonos with my tool.

My tool was able to discover the Sonos, so dont know why MC cannot. The DDD is served chunked, so pehaps MC cannot read chunked ?

Nevertheless my tool did suffer a timeout failure when pushing a test track to the Sonos. So maybe the OP still has some network issues. Its hard to say...

[bob]

I tested the Sonos with my tool.

My tool was able to discover the Sonos, so dont know why MC cannot. The DDD is served chunked, so pehaps MC cannot read chunked ?

Nevertheless my tool did suffer a timeout failure when pushing a test track to the Sonos. So maybe the OP still has some network issues. Its hard to say...

Well this will be easy enough to test with a build that only claims HTTP/1.0 support.

[AndrewFG]

Ah-Ha..

[bob]

I just tried the current version here with a Play:3 and it's working fine.

Are you using one of the Windows PC's to connect to the other Windows PC as a Media Center client?
If you were then the devices would only show up in MC's tree as There:xxxx devices.

Otherwise, I'm not sure what's up. I'm going to see if there is a firmware update for the Sonos...

[bob]

Updated firmware to 5.1.
Still works.

[bob]

And it actually supports SetNextAVTransportURI properly!

[yinmeout]

Guys - good news for the community and for me too as I managed to figure out what the root cause of this issue is - well, near enough.

Short version at bottom.

So I discovered that MC would find DNLA servers on two other PC's no problem. So I was pretty sure the issue was tied to the config of the server which normally runs MC and hosts all the content.

The box is a 2012 R2 essentials box (32g RAM) running lights out | hyper-v with an exchange VM (+ a bunch of test environments) / AD / WSUS / WDS / RD Gateway / Routing and Remote Access / NAP Server / IIS | DNS / Media Portal (TV recording) serviio - (TV Playback as well as MC).

Actually, I am very careful about the server and I test all proposed software in virtual environments and make copious notes on configuration / take snapshots before I make any changes etc etc. I have to say for all the complexity the thing is rock solid - it just works, perfectly. I get a very low voltage foot print for all the horsepower to do all my business and media requirements from one server anywhere in the world. This was the goal.

So I didn't want to say all that in the first place because the natural feedback would have been; OMG too much stuff on one box, how is that ever going to work. . . etc. However all process require is correct resources. Memory, registry configuration, access to ports, folders disk etc.
But. . . back to the point by comparison I found the difference in the case of the server vs the PC's where it works is, Serviio and Media Portal were also using Port 1900 as was DNS.exe (dns server) - but I didn't think that this 'could' be the problem since they were on the server long before MC was added and MC worked fine for months and months.

I used netstat -ano >myfile.txt and then searched the content with notepad for 1900.

I did some careful testing and found out that much of the configuration of the library / views etc is stored with the library which makes sense. The Program really handles just the playback | ui | and the DNLA services. So I did something rash and uninstalled MC and re-installed it. No difference  I had done a lot of tuning in the options but I guess over time I can get that back the way I liked it. Actually (thinking. . .) I can restore the registry settings from a backup - sorted! (done that it worked fine.) Although my auto-import settings seem to be missing - where are they are they stored?? please

It turns out though - by stopping all the other port contending services - that MC instantly found the Sonos rendering devices again as it used to. I then restarted all the other services which also use port 1900 and they all are working fine. Thereafter I have stopped MC and restarted it (to have it pick up the registry settings import and it finds the DNLA renderers no problem as it always did. Very odd.

Now under the covers windows is doing some clever stuff to allow all these processes to share this one port - that I don't know too much about as I haven't' dug in too far to MSDN. The other day when I first started to attempt to rectify this I found a fourth process attached to 1900 and it was some Microsoft port sharing process. It's not there any more. hmm. . .

Anyway short version - stop contending services and restart MC first - should fix it.

[yinmeout]

Sussed out the watched folders thing.

When you export the J River Registry it ends up with the watched folder part in this format:

<XMLPH version="1.0">
<Item Name="Ignore Special">1</Item>
<Item Name="File Types">m4a,aac,3ga,ac3,aif,aifc,aiff,au,snd,aa,caf,cue,dff,dsf,sacd,dts,flac,fla,m4p,m4b,mka,mid,midi,rim,rmid,ape,apl,mac,x-ape,mp4,mpc,mp+,x-musepack,mp3,mpa,mpga,jmx,ogg,opus,ram,ra,shn,tta,wav,w64,raw,l16,wv,wma,wax,x-ms-wma</Item>
<Item Name="Folder">\\server\Music\iTunes\iTunes Music\Classical\</Item>
<Item Name="Tags">(1:1)(1:0)</Item>
</XMLPH>

But you can't import that as a single REG_SZ string - so you have to edit it to look like below.

"Watch 0"="<XMLPH version=\"1.0\"><Item Name=\"Ignore Special\">1</Item><Item Name=\"File Types\">m4a,aac,3ga,ac3,aif,aifc,aiff,au,snd,aa,caf,cue,dff,dsf,sacd,dts,flac,fla,m4p,m4b,mka,mid,midi,rim,rmid,ape,apl,mac,x-ape,mp4,mpc,mp+,x-musepack,mp3,mpa,mpga,jmx,ogg,opus,ram,ra,shn,tta,wav,w64,raw,l16,wv,wma,wax,x-ms-wma</Item><Item Name=\"Folder\">\\\\server\\Music\\iTunes\\iTunes Music\\Classical\\</Item><Item Name=\"Tags\">(1:1)(1:0)</Item></XMLPH>"

[bob]

Guys - good news for the community and for me too as I managed to figure out what the root cause of this issue is - well, near enough.

Short version at bottom.

So I discovered that MC would find DNLA servers on two other PC's no problem. So I was pretty sure the issue was tied to the config of the server which normally runs MC and hosts all the content.

The box is a 2012 R2 essentials box (32g RAM) running lights out | hyper-v with an exchange VM (+ a bunch of test environments) / AD / WSUS / WDS / RD Gateway / Routing and Remote Access / NAP Server / IIS | DNS / Media Portal (TV recording) serviio - (TV Playback as well as MC).

Actually, I am very careful about the server and I test all proposed software in virtual environments and make copious notes on configuration / take snapshots before I make any changes etc etc. I have to say for all the complexity the thing is rock solid - it just works, perfectly. I get a very low voltage foot print for all the horsepower to do all my business and media requirements from one server anywhere in the world. This was the goal.

So I didn't want to say all that in the first place because the natural feedback would have been; OMG too much stuff on one box, how is that ever going to work. . . etc. However all process require is correct resources. Memory, registry configuration, access to ports, folders disk etc.
But. . . back to the point by comparison I found the difference in the case of the server vs the PC's where it works is, Serviio and Media Portal were also using Port 1900 as was DNS.exe (dns server) - but I didn't think that this 'could' be the problem since they were on the server long before MC was added and MC worked fine for months and months.

I used netstat -ano >myfile.txt and then searched the content with notepad for 1900.

I did some careful testing and found out that much of the configuration of the library / views etc is stored with the library which makes sense. The Program really handles just the playback | ui | and the DNLA services. So I did something rash and uninstalled MC and re-installed it. No difference  I had done a lot of tuning in the options but I guess over time I can get that back the way I liked it. Actually (thinking. . .) I can restore the registry settings from a backup - sorted! (done that it worked fine.) Although my auto-import settings seem to be missing - where are they are they stored?? please

It turns out though - by stopping all the other port contending services - that MC instantly found the Sonos rendering devices again as it used to. I then restarted all the other services which also use port 1900 and they all are working fine. Thereafter I have stopped MC and restarted it (to have it pick up the registry settings import and it finds the DNLA renderers no problem as it always did. Very odd.

Now under the covers windows is doing some clever stuff to allow all these processes to share this one port - that I don't know too much about as I haven't' dug in too far to MSDN. The other day when I first started to attempt to rectify this I found a fourth process attached to 1900 and it was some Microsoft port sharing process. It's not there any more. hmm. . .

Anyway short version - stop contending services and restart MC first - should fix it.

I'm not surprised it's a port 1900 conflict, that totally makes sense.
We are opening it in a way that should be friendly for sharing, I've checked this with AndrewFG.
Also, we are setting the multicast mode on it which should also be friendly.
It's possible one of the other pieces of software isn't doing this.
It's also possible the windows firewall gets confused when multiple apps are using that port.

[yinmeout]

It does also explain why AndrewFG's tool worked.

Another HUGE thank YOU! to all the people who helpfully contributed to this.