search

owntone / owntone-server

Linux/FreeBSD DAAP (iTunes) and MPD audio server with support for AirPlay 1 and 2 speakers (multiroom), Apple Remote (and compatibles), Chromecast, Spotify and internet radio.
https://owntone.github.io/owntone-server
GNU General Public License v2.0
2.09k stars 237 forks source link

Squeezelite ESP32 airplay device blacklisted #1823

Open LadnerJamie opened 3 days ago

LadnerJamie commented 3 days ago

Hello and thank you again for such an awesome piece of software, I use owntone daily, and it has the highest family approval factor of any of my installed software. I have used this software for almost 10 years(!) and appreciate all your support to the community.

I have recently purchased and set up an ESP32-A1S Dev Board Link to AliExp and after a fair bit of head scratching and hair pulling, have managed to get it up and running with airplay support using squeezelite. I realize that the Squeezelite devs have warned us that their implementation of Airplay is secondary to their LMS function, but it just seems so cool to run Airplay on one of these boards and I have already thought of a bunch of uses for it. However I think the issue I'm seeing with Owntone and the Squeezelite Airplay implementation may be with Owntone.

I have found that Owntone will drop the ESP32 device from it's list of speakers after a short while and it will not come back until i change the name of the device in the squeezelite software. It's like the device has been blacklisted, perhaps Squeezelite is doing something non-standard with the AP protocol to cause this?

I am able to reproduce this by running Squeezelite on my ESP32 board with Airplay turned on and then using the web interface of OT to airplay to the ESP32 speaker. I have not had an issue while actually playing to the speaker (and no static, thank-you) but when I stop air playing to the speaker it disapears from the speaker list. When it has disappeared from the speaker list, the ESP32 is still accessible through it's web interface, seen by LMS and can be connected to by another Airplay server (Android: Doubletwist) so I know that the board has not stopped functioning and has not self-rebooted. The missing ESP32 speaker will not come back in Owntone until I use the Squeezelite interface to change the device name (under the System 'tab') to another name and reboot the ESP32. Sometimes the device disappears the first time I stop playing to it, other times I can airplay to the device 3 or 4 times before it disappears, but still within a matter of less than 10 minutes. It has never disappeared while it is being played to, only when I stop playing to that device.

I have set the "permanent = true" and "reconnect = true" options in the owntone.conf but it does not seem to make any difference to the behavior. I'm hoping that you might be able to provide some insight what is going on or suggestions on what I could try to troubleshoot this. I have also tweaked a bunch of settings in the Squeezelite software including turning off the Spotify and LMS connection, but haven't been able change the ESP32 speaker from dropping off the availability list.

As I was trying to cull down the log file, I noticed that Owntone was attempting to send artwork to the ESP32, could that be too much information for it to handle? Just a thought...

Owntone 28.10 Raspberry Pi - Raspian Buster Speaker name: ESP32-A1S_8.3 Owntone_big.log

ejurgensen commented 3 days ago

Nice to hear that you and your familiy has been enjoying it for so long. Satisfied users are very motivating!

Yes, those ESP's are fun little things. I have one myself (currently it's in a drawer, however).

Your log shows that the speaker stops advertising itself:

[2024-11-10 23:22:52] [  LOG]     mdns: Avahi Resolver failure: service '08A6F7B1F474@ESP32-A1S_8.3' type '_raop._tcp' proto 0: Timeout reached
[2024-11-10 23:22:52] [DEBUG]     raop: Event for AirPlay device 'ESP32-A1S_8.3' (port -1, id 8a6f7b1f474, Active-Remote 4155634804)
[2024-11-10 23:22:52] [ INFO]     raop: AirPlay device 'ESP32-A1S_8.3' disappeared, but set as permanent in config

As to why it does that, it's difficult to say. You could try to run avahi-browse -r -k _raop._tcp on the RPi, just to check that Avahi also sees it as disappearing (and not appearing again). If it's the same with Avahi, then you would have to find out what's going on on the ESP. I don't remember if there is some sort of logging?

Btw, I don't understand why "permanent = true" isn't doing anything, but I suppose that isn't the main issue here. I'm thinking that even if the speaker stayed on the list, it probably wouldn't work, .

ejurgensen commented 3 days ago

I dusted off my esp32 to see if I could reproduce, but I couldn't. Mine stays in the list. Just tried once, though.

I found that you can see the esp32 logging just by telnetting to the device, so maybe that can provide some clues?