mirror of
https://github.com/lox-audioserver/lox-audioserver.git
synced 2026-04-25 22:35:53 +03:00
[GH-ISSUE #186] v 4 beta 7 loxone webapp issue #114
Labels
No labels
bug
enhancement
pull-request
released
released on @beta
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/lox-audioserver#114
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jurajs5 on GitHub (Feb 24, 2026).
Original GitHub issue: https://github.com/lox-audioserver/lox-audioserver/issues/186
I have issue with loxone web app system is stuck on "retrieving data....".
@rudyberends commented on GitHub (Feb 24, 2026):
Open the Loxone web app in Chrome or Edge.
Press F12 to open Developer Tools.
Go to the Network tab.
Enable Preserve log.
Press Ctrl+R to reload the page.
Wait until it gets stuck on “retrieving data…”.
Export the log as HAR.
Share the .har file.
Also helpful:
Go to the Console tab.
Send a screenshot of the errors (if there are any).
@Holzmusik commented on GitHub (Feb 24, 2026):
Please note that all music server functions of the Loxone apps only work on the local network, meaning either directly within your home network or via a VPN connection. I just tested it, and the web app works with the current Loxone firmware. You might need an update on your Miniserver. I'm currently showing version 16.2.0.
@jurajs5 commented on GitHub (Feb 24, 2026):
Archive.zip
log
@alexknig41 commented on GitHub (Feb 24, 2026):
For me it the opposite problem. On my Mac it works, iPhone and iPad saying "receiving data".
@rudyberends commented on GitHub (Feb 24, 2026):
Are you using the Loxone app or a browser?
How are you connecting to the Miniserver — via an internal IP (e.g. http://192.168.x.x) or an external hostname over HTTPS?
My suspicion is mixed content. For example:
• Miniserver loaded over https
• Audio Server websocket connecting over plain ws
Modern browsers will block this and report mixed content. The Loxone apps are also just web apps (Electron-based) and are generally less strict, which is why behavior can differ between devices.
However, to properly troubleshoot this I need more context. “Receiving data” by itself is not actionable. I know what triggers that state internally, but since this is not a general issue, it must be something very specific in your setup. Please provide:
• Exact client used (app + version or browser + version)
• How the Miniserver is accessed (full URL format) (v1 or v2 miniserver)
• Whether MiniServer is running behind a proxy/reverse proxy
• A debug log from connection attempt if possible
Without that, it is not possible to determine the root cause.
@rudyberends commented on GitHub (Feb 24, 2026):
This is not the har log, however I can already see mixed content messages. Could you provide the har logs? Also, could you give exact details as in the above request? If you are using a dns name in the browser, could you try with http://internal-ip?
@jurajs5 commented on GitHub (Feb 24, 2026):
I tried local IP, however loxone server redirects this immediately to external hostname. Any idea how to fix this?
@rudyberends commented on GitHub (Feb 24, 2026):
Using https? You have a v2 miniserver right?
If it works with the original audioserver then we can also make it work with our setup. However, I still need those logs to see what is going on. I know there is some sort of proxy server in there for the connection and we might need to specifically support this. If we cannot get it from the logs, we might need a trace with an original audioserver.
First let's try it with the logs. There should be an export to har. Use the steps as detailed before.
@Holzmusik commented on GitHub (Feb 24, 2026):
My Loxone app automatically switches between internal and external addresses depending on the network I'm connected to. Locally and via VPN, the app uses the internal address. When I'm connected via mobile data, it uses the external address. The fact that the music module only works to a limited extent from external networks isn't new; this was the case even before Lox-Audioserver.
@rudyberends commented on GitHub (Feb 24, 2026):
Not necessarily true. Those Loxone demo setups give you full control over the Audioserver using a remote connection. Loxone does this by letting the miniserver proxy the ws connection to the internal components. (Audioserver/intercom etc) it might not work with lox-audioserver right now. I have never tried. That doesn't mean we can't get it to work.
@jurajs5 commented on GitHub (Feb 24, 2026):
ye, I am using mini server V2 and original audio server.
log is here
192-168-1-50.504f94a10814.dyndns.loxonecloud.com.har.zip
@ultra-spark commented on GitHub (Feb 25, 2026):
I tested the solution on an RPi,
data recovery message in the iPhone app, also via the browser, works on the Windows app
@rudyberends commented on GitHub (Feb 26, 2026):
Are the phone apps on the same network? Do you use the same server hostname / ip? You are probably also using a v2 miniserver right?
It's probably related to the other issue, where an external hostname is used to connect to the miniserver. The miniserver (v2) will then try to proxy the connection to the audioserver instead of a direct client connection to the audioserver