mirror of
https://github.com/lox-audioserver/lox-audioserver.git
synced 2026-04-26 06:45:47 +03:00
[GH-ISSUE #106] Snapclients not appearing in lox-audioserver #53
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#53
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 @tokylo on GitHub (Jan 4, 2026).
Original GitHub issue: https://github.com/lox-audioserver/lox-audioserver/issues/106
Originally posted by @tokylo in #98
Originally posted by @rudyberends in #98
Hi, and thanks again for the clarification regarding the internal Snapserver in lox-audioserver.
I have updated my Snapclient systemd template to use the WebSocket connection as recommended, but unfortunately my Snapclients still do not appear in the lox-audioserver interface.
Here is my current /etc/systemd/system/snapclient@.service:
[Unit]
Description=Snapcast client %I
After=network.target sound.target
[Service]
EnvironmentFile=/etc/default/snapclient_%I
ExecStart=/usr/bin/snapclient --host ws://IPvonLoxAudioserver:7090 -s ${SNAP_CARD} --hostID %I
Restart=always
[Install]
WantedBy=multi-user.target
Questions:
Does lox-audioserver require any additional parameters or authentication for Snapclient connections?
Thanks in advance for your help!
@rudyberends commented on GitHub (Jan 4, 2026):
Ditch --host. Just use
ExecStart=/usr/bin/snapclient ws://IPvonLoxAudioserver:7090 -s ${SNAP_CARD} --hostID %I
After they are connected you should see them as snapcast players, but remember you might need to do a manual refresh
@tokylo commented on GitHub (Jan 4, 2026):
Unfortunately, using --host didn't work either
ExecStart=/usr/bin/snapclient --host ws://IPofLoxAudioserver:7090 -s ${SNAP_CARD} --hostID %I
@mr-manuel commented on GitHub (Jan 4, 2026):
You already used the command with
--host, you need to remove that. Just look again at the command in https://github.com/rudyberends/lox-audioserver/issues/106#issuecomment-3708243457@rudyberends commented on GitHub (Jan 4, 2026):
Yes, --host is deprecated. It does not work with a full url like you are using now. The snapclient will not connect using that command.
Just remove "--host" from the command.
@tokylo commented on GitHub (Jan 6, 2026):
Sorry, I had a typo in my previous message. I did try the ExecStart without --host as well. Unfortunately, neither version worked. However, I’ve managed to resolve the issue using Sendspin now, so I won’t be pursuing the Snapcast solution any further.
@rudyberends commented on GitHub (Jan 6, 2026):
no problem. Will close the one for now
@tokylo commented on GitHub (Jan 8, 2026):
Thanks to Re4DeR’s comment https://github.com/rudyberends/lox-audioserver/issues/98#issuecomment-3719343319 , I was finally able to identify the problem. I had Snapclient v0.31 installed, which lacks WebSocket support. After upgrading to v0.34, the Snapcast players appeared correctly.
Now I’m wondering: is there a way to control the Snapserver directly from Music Assistant?
AirPlay output from Music Assistant is still unreliable in my setup, and I’d prefer to stream directly to the Snapserver (lox-audioserver). Is native Snapcast output supported or planned?
@rudyberends commented on GitHub (Jan 8, 2026):
Good to hear that it works. Re4DeR’s comment indeed provides a clear description of how to set this up. The new protocol-related configuration options are not documented yet, so any feedback is very welcome.
If anyone has suggestions for improvements, I’m happy to add them either to the documentation or as inline setup steps.
The integrated Snapcast implementation is intentionally very lean and only includes the minimum functionality required for the dedicated Loxone Audio Server use case. It is not intended to be used as a full-featured Snapserver. Of course, additional functionality could be implemented, but only if there is a clear and valid use case for it.
Could you clarify what you are trying to achieve exactly?
If your goal is to stream audio from MA to a Loxone Audio Server, you can stream directly to a zone. When using the MA bridge, each zone is exposed as its own registered player. You can simply stream to that player. If you set the output of this player to Snapcast, the MA stream will be forwarded to the Snapclient.
Does this align with your setup, or do you have a different scenario in mind?
@tokylo commented on GitHub (Jan 9, 2026):
I still don’t fully understand how I can stream audio from Music Assistant directly to the lox-audioserver without using AirPlay or Snapcast.
What exactly is the “MA bridge”? Could you describe how it works or provide a screenshot?
My goal is the following setup:
At the moment, AirPlay from MA to the Loxone Audio Server is not always reliable, so I’m looking for a more stable way to stream directly to the server.
@rudyberends commented on GitHub (Jan 11, 2026):
I had not considered that approach myself, but that is indeed also possible. I am not sure why AirPlay input behaves so poorly when used through Music Assistant; I will need to look into that myself. When using an Apple device, AirPlay input works quite well.
You can add Music Assistant as a bridge provider on the content tab. This will give you access to the Music Assistant library, and it will also register all zones as Music Assistant players. These players are SendSpin-based, so they may work better for you.
@tokylo commented on GitHub (Jan 12, 2026):
Thanks for the clarification — I think I finally understand what was going wrong on my side.
I had accidentally entered my Home Assistant long‑lived token in the Music Assistant Bridge instead of the Music Assistant token.
Interestingly, it didn’t throw any error (I only noticed it later in the log), but it also didn’t show any players.
After correcting the token, all my lox-audioserver zones immediately appeared as SendSpin players in Music Assistant.
Now I can even see my YouTube Music playlists inside the Loxone app.
They show up as “Spotify”, but the content is actually YouTube Music.
As long as it works reliably, I don’t mind the label mismatch.
At this point, the only thing still pending for me is TTS.
I’m still experimenting with getting Music Assistant to generate TTS (Google or Piper) and stream it to the lox-players.
If I can’t get it working, I’ll report back with more details.
Thanks again for the hint about the MA bridge — that finally made everything visible and usable.
@rudyberends commented on GitHub (Jan 12, 2026):
No problem.
Regarding the labeling: please keep in mind that this project emulates an original Loxone Audio Server and is accessed exclusively through official Loxone clients. This means we are inherently limited by the feature set and terminology exposed by those clients, and cannot freely introduce new native concepts or UI structures.
To work within these constraints, unsupported services (such as Apple Music or Music Assistant) are exposed using so-called bridge providers. Technically, each bridge provider presents itself as a virtual Spotify account, because Spotify is the only extensible music source type that the Loxone clients can handle. This is a technical abstraction, not an attempt to misrepresent the actual service being used.
My goal is to make this as clear and user-friendly as possible. However, I also realize that terminology that feels logical during development may not always be immediately obvious to users encountering it for the first time.
With that in mind, I would appreciate it if you could review the Admin UI content again—specifically the section explaining bridge providers—and let me know whether you still feel it is "mislabeled". If so, I am very open to concrete suggestions on how the text can be improved or clarified further.