+- MinimServer Forum (https://forum.minimserver.com)
+-- Forum: MinimServer (/forumdisplay.php?fid=1)
+--- Forum: Digital Audio (/forumdisplay.php?fid=10)
+--- Thread: The control app thread (/showthread.php?tid=5354)
RE: The control app thread - Jota - 25-02-2023 02:51
Daft question but does the Lumin app require a Lumin network player?
RE: The control app thread - lyapounov - 25-02-2023 03:11
(25-02-2023 02:51)Jota Wrote: Daft question but does the Lumin app require a Lumin network player?
No
RE: The control app thread - lyapounov - 25-02-2023 03:15
(11-02-2023 18:07)tarnkappe Wrote: But you cannot stream qobuz using the openhome interface via lumin or linn app.
I am not sure what you mean, but I stream Qobuz through the lumin app without any problem...
RE: The control app thread - Peter StreamMagic - 25-02-2023 11:09
(25-02-2023 03:11)lyapounov Wrote:But it has to be an(25-02-2023 02:51)Jota Wrote: Daft question but does the Lumin app require a Lumin network player?
No
OpenHome streamer
RE: The control app thread - tarnkappe - 25-02-2023 11:48
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.
RE: The control app thread - simbun - 25-02-2023 12:02
(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.
RE: The control app thread - stefano_mbp - 25-02-2023 14:25
Great suggestion @simbun !
I set it to 30 this morning and till now (3/4 hours) Lumïn has never disconnected again
RE: The control app thread - simbun - 25-02-2023 15:08
I think it was @simoncn that said the Synology media center didn't exhibit similar behaviour because it broadcasts more frequently than MinimServer, so I went looking for an equivalent setting in BubbleUPnP.
In theory, if this works and you're having the same problem with MinimServer you may be able to proxy that too.
This change will marginally increase network traffic, so it might be worth playing with the interval.
I did try the Lumin app to test this change but I couldn't get it to fail in the first instance, although I am on Android.
I set up a multi-hour queue and set it off, putting the app in the background and coming back every 90 minutes or so, but it still showed the correct screen, queue and track position.
RE: The control app thread - simoncn - 25-02-2023 16:04
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.
RE: The control app thread - bubbleguuum - 25-02-2023 19:31
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.