Adding new UPnP renderer to device list issue

[storaid]

Hello, Tiki

If I’m running TuneBrowser for a while, the detected UPnP renderer device has been added to the device list.

But it shows up in the device list as “UPNP DEVICE[VOID]”.

I must restart the TuneBrowser to make it go back to normal status.

Thanks

[Tiki]

[VOID] is displayed when the UPnP Renderer did not respond correctly.

[storaid]

Hello, Tiki

I checked this problem using Wireshark.

The incorrect [VOID], a RST (RESET) packet, was due to a change in the port from 49152 to 49153.

These are all commonly used ports.

And the iFi device sent a NOTIFY signal to inform the TuneBrowser that a new session had started.

[storaid]

This should explain why restarting is the only way to make the device get back to normal status.

[Tiki]

storaid, sorry, but I cannot support all devices.

P.S. You are talking about SSDP protocol, and SSDP is using port 1900. So, I think 49152 and 49153 ports that you saying are client side port numbers. The port number on the client side changes with each session.

[storaid]

Hello, Tiki

You are talking about SSDP protocol, and SSDP is using port 1900. So, I think 49152 and 49153 ports that you saying are client side port numbers. The port number on the client side changes with each session.

YES

When the TuneBrowser is running, if the service endpoint’s port on the iFi UPnP renderer changes during device startup, from 49152 to 49153, it will show as VOID on the device list.

Originally, the renderer would send a SSDP – NOTIFY to indicate that the LOCATION of the service endpoint is port 49152.

I suspect that during the device initialization, the service endpoint’s port changes to 49153 in some stage.

It’s possible that the TuneBrowser could make some improvements in this case?

For example, periodically detecting NOTIFY to check for changes, then updating the UPnP Renderer on the device list.

I am currently in touch with the iFi vendor to ask why the service endpoint’s port is changed during device startup.

[storaid]

Hello, Tiki

This is my thought, please take it into consideration:

Some UPnP devices will change the listening port of their service endpoints during startup. However, under normal circumstances, these devices should continue to send NOTIFY SSDP packets to inform the control endpoint, like TuneBrowser, that the listening port of the service endpoint has changed.

This behavior is indeed possible with some UPnP devices.

Unless the control endpoint continuously monitors changes in NOTIFY packets to update the current device list, the only way is to wait for the UPnP device to complete startup, then start the control endpoint (such as TuneBrowser) to re-detect the UPnP device.

By then, the NOTIFY notification obtained from the UPnP device will already be the service endpoint currently in use.

[Tiki]

storaid, I understood what you saying.

It’s a case of the same USN with a different LOCATION.

I’ll see what I can do about it.

Thanks.

[Tiki]

I have released preliminary version of the TuneBrowser 5.4.2.

This version is trying to improve on this behavior.

Please try it when you have time.

[storaid]

Hello, Tiki

Thanks for your improvements

Seems like it’s working well with v5.4.2, even though the “port jump” problem occurs during device startup.

Thanks

[Tiki]

Thank you for your confirmation.

[投稿者]

投稿