bug bubbleupnpserver et qobuz

[jeffyjpn]

Valable aussi pour LMS. Pour ma part, c'est complétement anecdotique, je ne vois pas l’intérêt de fermer une appli pour gagner des pouillemes d'autonomie. Si c'est pour sonoriser un bureau, un local pendant des heures, je préfère utiliser un pc avec une page web (LMS ou InnuOS par ex.).
Par contre, que le flux audio fasse un aller et retour en wifi au téléphone avant d'arriver au lecteur avec l'appli bubbleUPNP me parait nettement moins anecdotique pour le coup. Qu'il faille installer un serveur pour éviter ce genre de comportement est assez curieux.

Si tu fais allusion à la solution BubbleUpnpServer et donc solution openhome, le flux audio ne fait absolument pas d’aller retour en wifi bien au contraire. Comme je l’ai dit, l’iPad ou téléphone ne sont là que pour piloter et non pour faire transiter le signal ... tout se passe au niveau « serveur » en considérant que l’appli est le « client »
D’ailleurs MconnectLite décode par exemple le MQA donc cela signifie bien que dans ce modèle là, Mconnect ne fait pas juste office de « télécommande » et que le flux audio transite par la partie client et c’est bien pour cela que le flux est coupé quand on ferme l’appli. Mais bon il est censé faire de l'UPNP pur donc ça ne devrait pas arriver.
Donc pour moi c’est exactement le contraire de ce que tu décris.
Et il ne s’agit pas de quelques pourcentages de batterie mais bien du fait que Mconnect te vide littéralement la batterie ... je l’ai expérimenté à de nombreuses reprises.