Can't send TTS to LMS/Squeezebox

I have TTS working fine with my Google Homes and Chromecast Audio, however if I try to send it to my Logitech Media Server players, no audio is produced. The files are generated to the designated cache folder and the player indicates that it’s being sent the stream from this location:
https://example.duckdns.org/api/tts_proxy/filename.mp3

Unfortunately, the audio doesn’t play and it’s not throwing any errors to the log. What could be the conflict here?

I can play the file in my browser at the above address. Perhaps LMS isn’t able to gain access to the /api/tts_proxy folder because of the SSL cert for some reason? Anyone else figured this out?

HA 37.0 AIO on RPi3
Let’s Encrypt SSL cert
base_url: example.duckdns.org
Router set for NAT hairpin

1 Like

I have exactly the same problem. So you are not the only one.
However, it seems that some users in the community got TTS working with SB.

I too think this can be an SSL issue.

Have you posted a bug report on github yet?

I think it’s network/dns issue. You’ve configured your base_url pointing to your external dns name that Google can grab speech file and send it to Google Home. Now look from internal device perspective which is behind NAT. It gets url with public name. It goes to dns server to get IP. DNS response with your public IP. Player tries to rich this IP and goes to your router. Router sees that it’s external interface and it’s kind of loop. To resolve this you can try to setup your internal DNS server which will hold all your internal IPs with external names.

Thanks for your reply! I barely get by following other’s examples so this is still a little over my head.

First I tried disabling the base_url parameter, then I changed the base_url to ‘192.168.1.111’, ‘192.168.1.111:8123’, ‘https://192.168.1.111’, ‘https://192.168.1.111:8123’. No luck with any of those.

I’m using pihole on the same machine as my DNS server to block ads so I poked around in there. I see these settings were enabled that said: “Note that enabling these two options may increase your privacy slightly, but may also prevent you from being able to access local hostnames”

never forward non-FQDNs
never forward reverse lookups for private IP ranges

I tried turning them off with no fix.

Would I need to make an entry to the hosts file? If so, what would I include?

If I remove the ssl_key and ssl_certificate entries from my config, tts to squeezebox works. It seems like LMS can’t reach the .mp3 files via https. I’m still looking for a solution if anyone has ideas!

Are you using self-signed certificate or from trusted. Certificate Authority?

Using the Let’s Encrypt certificate. It seems to work seamlessly withl other components.

I’ve googled a little. it seems that squezzebox do not support sell.

That’s a pity.
Would it be possible to get TTS to generate a LAN url instead? like http://192.168

I don’t know. Try to play with Base_url.

Ok I get it working via SqueezePlay but SqueezeLite it’s not working. Codec? or some thing. Same computer I run both types and only works via squeezPlay.

Any Ideas?

Is that with a SSL cert? If so, do you have base_url setup?

Yes with SSL all certs handled in Reverse Proxy/ Load Balancer Pound, and with Base URL set. It plays on the squeezeplay just fine just not squeezelite

Thanks for the info, I’ll try installing a Squeezeplay and see what happens.

@DrJeff: Do you have any “real” SB? If so, is it working on those?

@frelev

No I don’t have any real squeezeBoxes I only have 6 SqueezeLites and 1 squeezePlay and it only works on the SqueezePlay.

I tested on a few different instances of Squeezelite (raspberry Pi) and Squeezeplay (Mac) but got the same result on all. I also don’t have a real Squeezebox.

Does anyone know a command line option to push a stream to a squeeze instance for testing? I want to try pushing the same MP3 from a variety of locations and see if it makes a difference.

I use squeezy for that

Also you can use HTTP for that look at this site for starters

I posted this in another thread: Text-to-Speech (TTS) stops current media playing without resuming it

Basically, removing the “base_url” definition resolved my troubles. For completeness, I am running HA behind an NGINX proxy w/ Let’s Encrypt.