The control app thread

[simbun]

(25-02-2023 19:31)bubbleguuum Wrote:  The blastAliveInterval option if BubbleUPnP Server is really for use as a last measure and band-aid when nothing else works to fix a renderer or media server discovery issue.
It is quite heavy handed, triggering SSDP traffic at regular interval which will be received by all UPnP control points on the network listening for such traffic and maybe other UPnP devices that are not interested in it but will have to process it anyway (to finally discard it).
So I would advise to use it with caution and to set the interval at the highest value possible that fixes the problem.

Now I'll preface this with, a little knowledge is a dangerous thing!

We appreciate the caution on the use of this setting, but given the BubbleUPnP documentation gives no idea of what an "average" ssdp:alive interval would normally be (if there is such a thing) does the following make sense?

It appears that a few devices on my network - including MinimServer - have a CACHE-CONTROL max-age of 1800 (I can't seem to find a standard for this stated anywhere though), and the spec states to re-send it at "at a randomly-distributed interval of less than one-half of the advertisement expiration time, so as to provide the opportunity for recovery from lost advertisements before the advertisement expires", would starting blastAliveInterval at 850, then lowering as necessary be a sensible approach?
Just don't want someone starting at 30 then incrementing by 10 every day for months on end :-)

[stefano_mbp]

On my network Lumïn works fine with a value of 480, I tried 690 and 960 but it looses connection

[simbun]

That's excellent, I was hoping someone would get back with results.
Also good to see that it's nowhere near the lower end; a broadcast every 8 minutes isn't going to cause anyone any problems!

[lyapounov]

(25-02-2023 12:02)simbun Wrote:  

(25-02-2023 11:48)tarnkappe Wrote:  If you do not have an openhome streamer you can use bubble upnp server to install an openhome proxy for your streamer. With this you can use the lumin app. But: the lumin app does have the bug that it looses connection to the bubble server. You have to stop and restart the app then. So it might be better to use the linn app instead with bubble.

It sounds like it loses the connection to any renderer other than a lumin.
I did post a possible cure for that though here but I don't know if the poster ever tried it.

You do you do this when you don't use BubbleUpNP ? (I have an openhome renderer)

[lyapounov]

(25-02-2023 16:04)simoncn Wrote:  From the recent posts I have seen about this, this LUMIN app bug appears to affect renderer connections rather than server connections.

This indicates there is a bug in how the LUMIN app maintains UPnP connections/subscriptions with renderers. The LUMIN renderer works around this bug by sending frequent alive messages and so avoids being affected by this bug. Other renderers that correctly implement the UPnP specifications are affected by the bug unless they are proxied by BubbleUPnP Server with the special setting enabled.

This "ripple effect" is a great illustration of the problems caused when one component of a standards-based ecosystem fails to implement the required standard protocol correctly.

I hope the LUMIN app developers will fix this bug before other renderers are forced to also implement this incorrect behaviour for interoperability reasons.

Simon, seeing the way it has been solved by forcing bubble upnp to do a regular ping (like a heart bit), could it be possible than minimserver does this kind of handshake regularly also ? With the delay as a parameter ?

I love the Lumin app, but I find frustrating to have to constantly swipe it up and launch again.

[simbun]

(27-02-2023 05:06)lyapounov Wrote:  You do you do this when you don't use BubbleUpNP ? (I have an openhome renderer)

As well as offering OpenHome and transcoding functionality BubbleUPnP server acts as a compatibility layer, this is why this option exists, I doubt this will be available in other renderers, other than maybe the open source software renderers like RoPieee, LMS e.t.c.
I have no idea whether BubbleUPnP can proxy an OpenHome renderer though, but I would have thought so.

Regarding your question about MinimServer, BubbleUPnP can also proxy servers, but I understand you wanting it available directly.

[simoncn]

(27-02-2023 05:09)lyapounov Wrote:  Simon, seeing the way it has been solved by forcing bubble upnp to do a regular ping (like a heart bit), could it be possible than minimserver does this kind of handshake regularly also ? With the delay as a parameter ?

I love the Lumin app, but I find frustrating to have to constantly swipe it up and launch again.

The ohNet UPnP stack used by MinimServer does not provide any way to do this.

I raised this issue with the ohNet developers (many years ago). Their view is that the network should not be "flooded" with additional discovery notifications that would not be needed if other UPnP compoments are working correctly. They did increase the frequency of these announcements from what it had been previously.

As I understand it, this problem with the LUMIN app affects connections to renderers but does not not affect connections to MinimServer.

The correct solution for this problem is for the LUMIN app developers to fix their bug, not for every other UPnP component to add workarounds to compensate for it.

[simbun]

(27-02-2023 10:28)simoncn Wrote:  The correct solution for this problem is for the LUMIN app developers to fix their bug, not for every other UPnP component to add workarounds to compensate for it.

The problem is the app works fine with Lumin renderers :-)
Looking on the Google and Apple app stores the listing states numerous times that it's designed to work with Lumin hardware, so I can understand their point of view, it's not like they've offered it as a generic control point. It would be interesting to see how often the Lumin renderers announce themselves.

(27-02-2023 10:28)simoncn Wrote:  Their view is that the network should not be "flooded" with additional discovery notifications that would not be needed if other UPnP compoments are working correctly.

I know "flooded" is also a technical term, but it does sound dramatic. It's my understanding that what @stefano_mbp has implemented (requiring an alive broadcast every 480 seconds) is equivalent to adding another renderer to his LAN, or running another instance of MinimServer, is that correct?

[Jota]

403
Forbidden

Access to this resource on the server is denied!

Damn. I made a huge post but all I get is that 403 nonsense.

I'll edit this again when I have time later.

[simoncn]

(27-02-2023 12:45)Jota Wrote:  403
Forbidden

Access to this resource on the server is denied!

Damn. I made a huge post but all I get is that 403 nonsense.

I'll edit this again when I have time later.

My apologies for the inconvenience. I have just created a new thread in the Administration section of the forum explaining what to do if this happens and providing an opportunity for other users to share what has caused them to experience this error.