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).

[kenkuo]

Beta 3 also looks to be exact same behavior, still able to stream to the one exposed bubble upnp dlna device just fine:
log.txt

[dheijl]

For some reason you're still running the original beta. This line:

Renderer Denon AVR-S760H Denon AVR-S760H ip 192.168.1.243 at urlbase http://192.168.1.243:60006/ has 9 services

should be similar to this one:

Renderer Marantz UPNP UpMPD ip 192.168.0.131 at location http://192.168.0.131:49152/uuid-fdfabe96-b6c6-92ff-31dd-dca63239e1f0/description.xml has 7 services

I have no idea how this is possible, as I delete the old setup every time and replace it with the new one on Github.

But it certainly explains why you don't see any changes...

[dheijl]

I downloaded the setup from Github and it installed the latest version, showing the correct messages in the log.

I replaced it again, but this time the app should show the version 1.12.3-b3 in the title bar:

[kenkuo]

I uninstalled the application then reinstalled it. Looks to be working now, although volume sliders don't do anything. Great work and thanks for the rapid response again.

[dheijl]

I have no idea if Bubble or Chromecast support changing the volume, reading it out seems to work though.

Looking at your screenshot, I see that the SSDP interval is extremely short, if you're on shaky WiFi connections it might interfere with the streaming.

I will wait a couple of days before releasing this officially, in case you find any problems.

One restriction when using devices sharing the same IP address: if you start streaming from swyh-rs, and terminate it with some other means (breaking the streaming connection from the device end), swyh-rs is not able to reflect this on the button, it will remain lighted even though the device is no longer streaming. The streaming code only has the IP address of the device that requests HTTP streaming, and there is no way to link this back to the DLNA device that got the Play command from the GUI (except guessing)

[dheijl]

Oh, and thanks for testing this and bearing with my attempts to fix it. Much appreciated!

[dheijl]

Fixed with release 1.12.3.