Issues w UPNP and BrowseMetadata.

What args are you passing exactly? I don’t recall ever seeing anything like this, I recommend rebooting the target device.

Thanks @controlav. The problem is on all my S2 (SW) players and I don’t have it on my S1 (SW) players.

I would be the usual:

ObjectID this would be the object id of an ITEM not a CONTAINER

BrowseFlag = BrowseMetadata

Filter = *

StartIndex = 0

RequestCount = 0

SortCriteria = <blank>

Response:

<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/"></DIDL-Lite>

with NumberReturned = 0

TotalMatches = 0

UpdateId = 0

Setting RequestCount to a non-zero value makes no difference

What is the actual ObjectID, and how did you get it? I am a few thousand miles way from either of my systems right now, but apart from the RequestCount being 0 (something I have never done) it doesn’t look dubious.

Oh and what is the UserAgent you are using?

The ObjectID depends on the content you have on your Sonos Player, so in my case I navigate either from A:TRACKS or A:ALBUMS into a song. With the ObjectId of that song item, I retrieve the meta data to get the author, art etc but more importantly the “res” so I can instruct the player to play this item.

I’ve been doing this for a decade now and support Sonos homeautomation for HomeSeer now for about 11 years. Over the years I wrote my own UPNP stack from scratch, which I have been using now for nearly 8 years. I also use Intel’s UPNP Device Spy and they all agree, it worked till very recently (and still works with S1 SW) and either Sonos broke it or deliberately removed it .. or it needs additional header information as part of some authentication scheme. 

I’ve been doing this for over a decade in commercial products, and have never seen any issues like this. I also use my own UPnP stack. Suggest you carefully diff the call you are making for a given item to the call that the official app is making.

However: are you saying that making similar calls via the UPnP Spy app also is not working on your system? I would question something weird on your network if that is failing similarly (eg firewall, broken router etc).

So what was the conclusion here @dcorsus ?

A bit of a multipronged answer:

1. the result of a browse query whether I use my own stack or DeviceSpy is the same answer, there are no failures, the answer for an S2 based setup is different (and wrong) from an S1 based system. Something changed and you can see that sorta default response a few postings above. It doesn’t fail (no error)  …. just no data!
2. So how did I solve this: by rewriting my code and by using the metadata when you retrieve the PARENT’s information using BROWSE with option BrowseDirectChildren.
3. As to your question how the Sonos APP does it, well if you snoop it, you see it doing the same, in that when you navigate into content, say from artist, to album to track, Sonos retrieves the containers and navigates into its children , you don’t see it actually retrieving the item, just its parents container ,which provides all children (tracks) with their metadata.

So I have it working again because I found a workaround not because I solved it.

Clear as mud?

I have a suspicion that perhaps Sonos has optimized its DB structure a bit to optimize for memory/storage and perhaps figured that they didn’t need any indexing for accessing items directly and return it’s metadata, that by having it indexed at the parents container, it was good enough. 

Just my suspicion.