Can't send TTS to LMS/Squeezebox

sota · May 31, 2020, 6:34am

For anyone with a SqueezeBox radio you need to apply a patch before upgrading to LMS 8. See here: https://forums.slimdevices.com/showthread.php?111938-Squeezebox-Radio-would-not-connect-to-LMS-8-quot-Update-required-quot

Moonbase59 · June 5, 2020, 8:17am

Good news, guys! Thanks to the work of philippe44 and mherger, this issue has now been fixed in the LMS 7.9.3 - 1591161343 nightly.

If using PicoTTS (which generates 16kHz mono WAV files), you might still hear a small “click” sound at the beginning. If that disturbs you, just add a custom-convert.conf with this contents and it will transcode to FLAC and play flawlessly:

# For Home Assistant PicoTTS, brute-force conversion
wav flc * *
	# R:{PATH=%F}T:{START=trim %t}D:{RESAMPLE=-r %d}
	[sox] -q $PATH$ -r 48000 -c 2 -t flac - $START$

On Linux, you’ll find (or have to create) this at /etc/squeezeboxserver/custom-convert.conf.

I’ve tried this configuration with both Google Translate TTS and PicoTTS, using SSL with a valid cert (Let’s Encrypt) on my server. My configuration.yaml looks like this:

# Text to speech
tts:
  - platform: picotts
    language: 'en-GB'
    base_url: https://has1.example.com
    cache: false
  # - platform: google_translate
    # base_url: https://has1.example.com
    # language: 'en'
    # cache: true
    # time_memory: 300

The base_url used is the same as in my http: section, and I don’t cache PicoTTS messages on the disc (they will still be held in HA’s memory for a short time).

Note: You will not be able to use PicoTTS with HassOS/HASSIO, which is a shame. One of the reasons I stuck with Hassbian. I’ve heard that you can install HASSIO on Raspbian, though, which might make it work.

Happy TTS’ing!

Moonbase59 · June 5, 2020, 8:51am

@carsten_h: You need a valid cert for this to work. That again is most probably for a server name, not for an IP address in the private range. The cert must match the server name, otherwise it will be rejected. Using a fallback mechanism, LMS then goes and tries the same address without SSL (http:) – which isn’t usually available in a “standard” HA installation if using certs (404 error).

The “forever counting up seconds and not playing anything” has been addressed in the 7.9.3 (and 8.0) nightlies of June 3, 2020 and after.

carsten_h · June 5, 2020, 9:15am

I tried it before with my external duckdns address with https and certificate. But that didn’t work also.

Yes, I saw that at the LMS board.

But in the meantime TTS is not longer working in Home Assistant. I can input a text, but LMS is getting nothing. And so far I see there is nothing in the log.

Moonbase59 · June 5, 2020, 10:08am

Did you already install LMS 7.9.3 - 1591161343 or above?

Using the external https: address seems the way to go (with a valid cert). Then again, you call up an external address that’s actually inside. Using IPv4, this might give NAT translation/looping problems with some Internet routers. As far as I know, well-configured OpenWRTs and AVM Fritz!Boxes handle that situation correctly.

It’s actually unfortunate that many vendors (like Google with ChromeCast) go their own ways here, and you’ll need some knowledge on setting up all the networking correctly. In my case, running (and routing) a mixed IPv6/IPv6 network, it was even harder:

I had to explicitly disable IPv6 on my HA Raspberry, because internally, IPv6 was preferred but HA would only communicate either IPv4 or IPv6. I have now running my HA instance on IPv4 only (and only route my HA server via IPv4 to the Internet, so my DNS provider wouldn’t give both IPv4 and IPv6 addresses as a DNS response, which in turn will make LMS or the players crap out if they pick the IPv6 address from DNS while HA only serves IPv4).

Also, almost all DNS services out there will mess up IPv6 prefix changes, you’d have to run a separate DynDNS updater on the HA machine. Which I didn’t want, so I opted for using AVM’s “myfritz.net” DynDNS service, which seems the only one doing everything right. But they give you crazy DNS names. Sigh. (I do use a Fritz!Box.)

carsten_h · June 5, 2020, 10:13am

Yes, I am using version 8 (currently: 8.0.0 - 1591161678) since a few months.

Yes, that is correct! I also use a Fritz!Box.

carsten_h · June 5, 2020, 10:24am

I tried it using this in configuration.yaml:

tts:
  - platform: google_translate
    base_url: https://xxxxxxxxxx.duckdns.org:8123

But still nothing is happening when input text in the lovelace media player. There is nothing in the logs, no reaction on the LMS side, simply nothing.

Moonbase59 · June 5, 2020, 10:26am

So if you have IPv4 Internet access only, easy-peasy. If you got true IPv6 (not DSL Lite or such, check online using an IPv6 tester), your best bet would be to activate MyFritz, set the HA machine to IPv4 only, then use only “MyFritz-Freigaben” in your Fritz!Box (not the port forwarding ones!) and check in your MyFritz account that your router is actually only advertising IPv4 DNS. You can also check with tools like dig if there are more than one (IPv4) addresses returned (i.e. AAAA records).

Then setup your HA to use IPv4, in http: and tts: use the external https: address (most likely something like hassio.xxxxxxxxxxxxxxxx.myfritz.net) as base_url and check it out.

If you’ve setup some test files in your config folder’s www subfolder, you can also try these. LMS should eventually see links like:

https://hassio.xxxxxxxxxxxxxxxx.myfritz.net/api/tts_proxy/d09a9a529692ab7770f3303a38f4e064e56f7402_de_-_google_translate.mp3
https://hassio.xxxxxxxxxxxxxxxx.myfritz.net/api/tts_proxy/de066ee453c3e6c28855d25025dc83cbd06dfd33_en-gb_-_picotts.wav
https://hassio.xxxxxxxxxxxxxxxx.myfritz.net/local/testfile.mp3

and be able to play them.
Good luck!

N.B.: Also noteworthy: Many tools silently assume port 443 for https: connections. That’s why I opted for running HA’s https: on port 443, not 8123.

My http: section in config.yaml looks like this:

http:
  # Secrets are defined in the file secrets.yaml
  # api_password: !secret http_password
  # Uncomment this if you are using SSL/TLS, running in Docker container, etc.
  # base_url: example.duckdns.org:8123
  base_url: has1.xxxxxxxxxxxxxxxx.myfritz.net
  ssl_certificate: /etc/letsencrypt/live/has1.xxxxxxxxxxxxxxxx.myfritz.net/fullchain.pem
  ssl_key: /etc/letsencrypt/live/has1.xxxxxxxxxxxxxxxx.myfritz.net/privkey.pem
  #ssl_profile: intermediate

carsten_h · June 5, 2020, 10:30am

The strange thing is that it worked before like I did it, the only thing that changed are new hassos and Home Assistant versions
I also tested the links that LMS got and they worked without any problem in a browser from outside/inside my net.
But now nothing is happening when sending text. I don’t think that this is a IPv4 problem. I have a full IPv4/IPv6 internet access.

Moonbase59 · June 5, 2020, 10:39am

Believe me … see: https://github.com/Logitech/slimserver/issues/340

More often than not, if you have full dual-stack, LMS (or the player if it’s on direct streaming) will pick the IPv6 DNS response, which will fail (because HA is either/or, or your DynDNS service gives you the wrong IPv6 address) and thus never play.

LMS does try to read the first few bytes of a stream to determine what it is (like show you the ID3 tag), then shoves over the playout to entirely different routines (or the player), which in turn fails reading from the address given. Took us long enough to get behind all that.

carsten_h · June 5, 2020, 10:47am

I do!

But I think I first have to find the problem that nothing is created.
Before there were files in the config/tts folder of Home Assistant. Now they don’t get even created. There are only the old ones, no new ones. The last are from May, 20th, nothing later. That was the last day I tested it.

Moonbase59 · June 5, 2020, 10:52am

Maybe you have cache: false in your tts: section, or it’s the new default?

HA uses two caches for TTS: One in memory, one on the disc. For TTS, the extra cache on disc is almost never needed, so I turned it off. And you would have to clear out the disc cache manually (or via an automation), because HA doesn’ŧ auto-clean it. time_memory: is only for the mem cache.

carsten_h · June 5, 2020, 11:00am

I tested the link from my previous post, because the file is still there:

https://xxxxxxxxx.duckdns.org:8123/api/tts_proxy/b0aea2ed...008854ba5fb9_en_-_google_translate.mp3

I tested it direct in LMS webpage.
First with https://xxxxxxxx.duckdns.org:8123
then with https://192.168.178.108:8123
then with http://192.168.178.108:8123
but everytime I am getting this error:

[20-06-05 12:51:45.9511] Slim::Utils::Scanner::Remote::__ANON__ (192) Error: Can't connect to remote server to retrieve playlist for, http://192.168.178.108:8123/api/tts_proxy/b0aea2ed...0008854ba5fb9_en_-_google_translate.mp3: Error reading headers: Server closed connection without sending any data back at /usr/local/slimserver/CPAN/Net/HTTP/Methods.pm line 391.
	...propagated at /usr/local/slimserver/CPAN/Net/HTTP/NB.pm line 32.

carsten_h · June 5, 2020, 11:08am

When I look inside the documentation I see true is default, I set it now to false. But it changes nothing, nothing is send to LMS.

Moonbase59 · June 5, 2020, 11:09am

It would only change whether files are created in the config/tts folder or not.
Even without the file cached in tts, the api can still hand out the TTS message from memory, usually (=default) for 300s.

Moonbase59 · June 5, 2020, 11:14am

Re the three links above:
Do all of them play in a browser, or VLC, or can be gotten using wget?

The log message looks much like what I had before I had setup everything correctly. The Remote scanner can simply not read from http://192.168.178.108:8123/api/tts_proxy/b0aea2ed...0008854ba5fb9_en_-_google_translate.mp3.

This is usually true for HA if configured with a cert (it disables http: access).
Did you give HA the ssl_certificate and ssl_key locations? (Don’t know if that is necessary in your version, here it is [Hassbian]).

carsten_h · June 5, 2020, 11:20am

Both https-links are working in Safari on Mac.

Yes, I did. Everything else is working fine accessing Home Assistant.

http:
  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem

That are the correct files, I am getting through Let’s encrypt from the duckdns integration.

carsten_h · June 5, 2020, 11:24am

I made another test. I logged in to the piCorePlayer Pi with LMS on it and tested:

wget https://xxxxxxxx.duckdns.org:8123/api/tts_proxy/b0aea2e...071ea0008854ba5fb9_en_-_google_translate.mp3

in the shell.

I got the file:

-rw-r--r--    1 tc       staff       435177 Jun  5 13:22 b0aea2e...8854ba5fb9_en_-_google_translate.mp3

Moonbase59 · June 5, 2020, 11:29am

Ok, so you should have lost all http: connection to HA. Might want to check that. (A HA “feature”.)

So it could be:

Giving LMS a http: link without offering HTTP on HA’s side.
Giving LMS a https: link, but it falls back to http: because https not working.
https not working because …
- using IPv6 address and HA configured for IPv4
- using IPv4 address and HA configured for IPv6
- NAT looping problem if IPv4 (not on Fritz!Box)
- wrong IPv6 address gotten from DynDNS

Do you run HA on a Pi? If so, you really might want to disable IPv6 on that and give it a shot again.

Also, check again if the IPv6 address(es) DuckDNS gives you in its DNS response are correct. I seem to remember you need the ULA address, with the prefix part correct.

Moonbase59 · June 5, 2020, 11:30am

Did wget make a retry? That would usually indicate either the IPv4 or the IPv6 address not working.