BubbleUPNP devices not being discovered

[kenkuo]

swyh.txt

The devices are responding to SSDP but not sure what's going on after that. These all show up in swyh original but not in -rs

[dheijl]

please attach the complete (unedited) debug log.

[kenkuo]

log.txt

[dheijl]

Thanks.

The problem is simple: the location header in the SSDP response should be uppercase "LOCATION:", but for some reason Bubble uses "Location:". You will see in your log that all other devices properly use LOCATION.

Idem for the ST header, Bubble uses St.

Easily fixed, probably tomorrow.

[dheijl]

Should be fixed in release 1.12.1.

[kenkuo]

Still having the same issue:
log.txt

[dheijl]

You're right, the comparison was already case insensitive, so I'll have to investigate properly...
Sorry about that.

[dheijl]

The reason: it's the only device I have ever encountered that puts the Location header last.
Everyone else puts it at the top, and I stopped scanning at the St header, so the Location header was missed.
I'll yank 1.12.1 and release 1.12.2.

[dheijl]

This time I hope I fixed it properly. Sorry for the mess...

[kenkuo]

log.txt
Almost there :)
Now only "Living room speaker" shows up in UI but I can see all the other devices are being discovered now in the log.
There should be 4 devices exposed from BubbleUPNP as DLNA:
Living room speaker
Master Bedroom speaker
Entryway speaker
Speaker group

Let me know if you need any more info from me, thanks for your quick responses

[kenkuo]

If I expose an openhome renderer in BubbleUPNP that one takes the place of the "Living room speaker (DLNA)" renderer in the UI. Possibly only the first BubbleUPNP renderer discovered is being properly shown?
log.txt

[dheijl]

For swyh-rs a "device" is identified by it's IP address as discovered in the SSDP responses.

But Bubble UPNP uses the same IP address and port number for every endpoint:

Location: http://192.168.1.181:33065/dev/e8dbf26b-de8f-4c96-ffff-ffffe567e8f1/desc.xml
Location: http://192.168.1.181:33065/dev/e8dbf26b-de8f-4c96-0000-0000002ea642/desc.xml
Location: http://192.168.1.181:33065/dev/e8dbf26b-de8f-4c96-ffff-ffffe11e713e/desc.xml
Location: http://192.168.1.181:33065/dev/e8dbf26b-de8f-4c96-0000-00002fb4d2f6/desc.xml
Location: http://192.168.1.181:33065/dev/e8dbf26b-de8f-4c96-0000-000041c918c7/desc.xml
Location: http://192.168.1.181:33065/dev/e8dbf26b-de8f-4c96-0000-000041c918c7/desc.xml
Location: http://192.168.1.181:33065/dev/e8dbf26b-de8f-4c96-ffff-ffffe567e8f1/desc.xml
Location: http://192.168.1.181:33065/dev/e8dbf26b-de8f-4c96-0000-0000002ea642/desc.xml
Location: http://192.168.1.181:33065/dev/e8dbf26b-de8f-4c96-ffff-ffffe11e713e/desc.xml
Location: http://192.168.1.181:33065/dev/e8dbf26b-de8f-4c96-0000-00002fb4d2f6/desc.xml

So the last one to respond wins, and Openhome is preferred to AV.

As it is now, swyh-rs can not handle that. Now if the port numbers were different, I could perhaps support that, but if both are identical they are one device.

[dheijl]

Looking at the code I think it's not a monumental task to support this, but I would need your assistance in testing my attempts to implement the necessary changes.

[dheijl]

If I release a new beta to test, do you need the setup or is a debug binary sufficient?

[kenkuo]

If it's just replacing the swyh-rs.exe I can handle that

[dheijl]

There's a new beta setup.

[kenkuo]

log.txt
Looks to be the same result

[dheijl]

I expected problems but I thought the buttons for the players would at least show up.

However, since the streaming is totally disconnected from UPNP, I have no means to connect a device that is currently streaming to the buttons in the GUI, and I don't think I can solve that. I only have the IP address of any device that starts streaming, and nothing more. So it's probably not something that I can support reliably.

[dheijl]

But I'll see if I can up with something that works if you are prepared to wait a bit.
As a first step I'll have to introduce a new concept in the code, a sort of "unique id" based on the URL in the SSDP Location header.

[dheijl]

The beta has been updated. I think it should work now.

Some things will probably no longer work, let me now if you find something (or if it still doesn't work at all).

[kenkuo]

Looks to be the same with beta 2, albeit with no regression either from what I can tell.
log.txt

[dheijl]

The beta has been updated again. I think it should work now, honestly :)

Some things will probably no longer work, let me now if you find something (or if it still doesn't work at all).