Can you proxy via HA, like tts_proxy? #794
-
I'd like to be able to use a single port for HA and MASS. It seems that something's changed and MASS now uses 8095 - I don't remember that being the case several versions ago. I would like to be able to "proxy" the MASS stream and use a single port (I use 443 with an SSL cert.) Of course if I do that with HA - MASS now requests it's audio to play on 8095 and http, so audio doesn't play anymore. Am I missing a configuration setting or tweak? If I were to proxy /mass/ to port 8095, what would be needed for MASS to pass that fqdn, protocol and path to the streaming devices? If it's not possible, this may end up being a feature request... |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 4 replies
-
This has always been the case. The mass api and web interface is hosted by HA but the streaming is local only on a dedicated tcp port. |
Beta Was this translation helpful? Give feedback.
-
I am going to share a bit of a more detailed answer here because this question seems to popup more often for users with (over)complicated setups. Music Assistant uses the Home Assistant webserver for all communication. So the frontend of MA is using the HA webserver and authentication etc. Besides that, MA needs to be able to stream audio to client devices in a reliable way that works with all players. This is not about running Home Assistant web interface behind reverse proxy etc. it has nothing to do with a web interface. To prevent issues with DNS lookups (and additional overhead and latency!) we communicate the IP ADDRESS of the stream webserver to the clients. This IP address is resolved automatically from the "internal url" field in your Home Assistant config. It seems people want to have that audio stream service behind proxies and/or HTTPS and overcomplicate it. For example google cast players have the google dns servers hardcoded and will never be able to resolve internal dns names. That is why the stream service is hosted on its own as-simple-as-possible http port, otherwise I could have proxied it on the HA webserver. I did that for a reason, keep it as bullshit simple as possible to prevent issues. So, I'm not a big fan of making this configurable because it will cause more support to handle and it will most likely not work in a lot of situations. Maybe some sort of hidden environmental variable that nobody knows about but then you are completely on your own with regards to support. I am busy enough supporting the regular setup. What's wrong with opening a tcp port in your LOCAL network ? Just make sure that the TCP port 8095 is reachable from your audio devices in your LAN. There's nothing to secure about audio data. Come on, even the source audio from the streaming providers is hosted on HTTP for a reason! I respect all of your setups but I ask you to respect me that I do not want to add something to my code that is going to potentially break audio or cause me support. If you don't like it, move away and do not install Music Assistant. So, if this really a thing I could add an environmental variable to set to override the default stream IP that is sent to players but I am not going to provide support if you are having issues with the audio stream as a result from that. I'm working for over 3 years on this project with various players and I can assure you that is going to cause real issues. Don't blame me, but blame the MCU creators in the various audio devices. |
Beta Was this translation helpful? Give feedback.
-
Hi! EDIT: I am able to reach the proper authentication address when I DO NOT USE CLIENT ID. Now I get strange things in my MA logs: |
Beta Was this translation helpful? Give feedback.
I am going to share a bit of a more detailed answer here because this question seems to popup more often for users with (over)complicated setups.
Music Assistant uses the Home Assistant webserver for all communication. So the frontend of MA is using the HA webserver and authentication etc.
Besides that, MA needs to be able to stream audio to client devices in a reliable way that works with all players.
We do this with a secondary, simple webserver hosted by default on port 8095 to serve the audio stream to clients.
This additional webserver is HTTP only for a reason: A lot of clients do not like the audio served from HTTPS and it adds a lot of overhead that is simply not needed just for a…