Can't locate Sonos Play:1

[rowanoulton]

Hi there,

Try as I might, I can't get Airconnect to find my Sonos Play:1 when I run it inside this container. Running a binary of Airconnect directly on my machine works. I run an Amplifi HD base station with an M1 Mac mini. The mini is connected by ethernet and wireless but the problem persists regardless of which I use (or whether I disable one or the other).

Here's what I've tried:

docker run -d --net=host 1activegeek/airconnect

Ends with these logs:

[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 30-install: executing...
Checking for valid arch options
Proceeding with aarch64 arch
[cont-init.d] 30-install: exited 0.
[cont-init.d] 90-custom-folders: executing...
[cont-init.d] 90-custom-folders: exited 0.
[cont-init.d] 99-custom-scripts: executing...
[custom-init] no custom files found exiting...
[cont-init.d] 99-custom-scripts: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
2021-08-12 02:49:03,742 CRIT Supervisor running as root (no user in config file)
2021-08-12 02:49:03,744 INFO supervisord started with pid 288
2021-08-12 02:49:04,766 INFO spawned: 'airupnp-aarch64' with pid 296
2021-08-12 02:49:04,770 INFO spawned: 'aircast-aarch64' with pid 297
2021-08-12 02:49:05,784 INFO success: airupnp-aarch64 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-08-12 02:49:05,784 INFO success: aircast-aarch64 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

After reading #13, I attempted to hardcode my host IP address:

docker run -d --net=host -e AIRUPNP_VAR="-b 192.168.133.133 -l 1000:2000 -d all=debug" 1activegeek/airconnect

... but that produced different problems:

[cont-init.d] 30-install: exited 0.
[cont-init.d] 90-custom-folders: executing...
[cont-init.d] 90-custom-folders: exited 0.
[cont-init.d] 99-custom-scripts: executing...
[custom-init] no custom files found exiting...
[cont-init.d] 99-custom-scripts: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
2021-08-12 02:53:16,857 CRIT Supervisor running as root (no user in config file)
2021-08-12 02:53:16,859 INFO supervisord started with pid 287
2021-08-12 02:53:17,866 INFO spawned: 'airupnp-aarch64' with pid 296
2021-08-12 02:53:17,871 INFO spawned: 'aircast-aarch64' with pid 297
2021-08-12 02:53:17,879 INFO exited: airupnp-aarch64 (exit status 1; not expected)
2021-08-12 02:53:18,883 INFO spawned: 'airupnp-aarch64' with pid 308
2021-08-12 02:53:18,883 INFO success: aircast-aarch64 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-08-12 02:53:18,892 INFO exited: airupnp-aarch64 (exit status 1; not expected)
2021-08-12 02:53:20,896 INFO spawned: 'airupnp-aarch64' with pid 316
2021-08-12 02:53:20,901 INFO exited: airupnp-aarch64 (exit status 1; not expected)
2021-08-12 02:53:23,912 INFO spawned: 'airupnp-aarch64' with pid 324
2021-08-12 02:53:23,924 INFO exited: airupnp-aarch64 (exit status 1; not expected)
2021-08-12 02:53:24,927 INFO gave up: airupnp-aarch64 entered FATAL state, too many start retries too quickly

And when I shelled in and tried it manually from within the container, it hangs on Presence checking:

# ./bin/airupnp-aarch64 -d all=debug -l 1000:2000
[02:55:31.639651] main:1420 Starting airupnp version: v0.2.50.5 (May 24 2021 @ 15:13:58)
[02:55:31.640008] main:1428 no config file, using defaults
[02:55:31.644015] Start:1130 Binding to 192.168.65.3:49152
[02:55:51.001213] UpdateThread:726 Presence checking
[02:56:11.001074] UpdateThread:726 Presence checking

Trying to hardcode the host IP from inside fails too:

# ./bin/airupnp-aarch64 -d all=debug -l 1000:2000 -b 192.168.133.133
[02:56:40.626513] main:1420 Starting airupnp version: v0.2.50.5 (May 24 2021 @ 15:13:58)
[02:56:40.626984] main:1428 no config file, using defaults
[02:56:40.630742] Start:1120 UPnP init failed: -208
[02:56:40.630814] main:1461 Cannot start

After using --net=host, I'm surprised by the output of ifconfig inside the container, but then again I have a pretty crude understanding of networking in Docker:

# ifconfig | grep 192.168
inet 192.168.65.3  netmask 255.255.255.0  broadcast 192.168.65.255
inet 192.168.65.4  netmask 255.255.255.255  broadcast 0.0.0.0

For completeness, I tried binding to those IPs too (the top is wireless, the bottom wired) with the same results as above.

Finally, here's what I get when I run Airconnect outside a container (it just works):

[14:51:57.619972] main:1420 Starting airupnp version: v0.2.50.5 (May 24 2021 @ 15:14:58)
[14:51:57.621510] main:1428 no config file, using defaults
[14:51:57.623508] Start:1130 Binding to 192.168.133.133:49152
[14:51:59.196348] AddMRDevice:1008 [0x7feee8008000]: adding renderer (Lil Speaker)
[14:51:59.200643] MasterHandler:669 [0x7feee8008000]: subscribe success

I feel like I've missed something obvious in all this thrashing around. Any help you could render me would be much appreciated.

Thank you for the superb project :heart:

[1activegeek]

I'm not sure I can offer much advice here - it appears by your first bit of code snippet showing logs that it is working as intended, just not showing devices. I would say that about 80-90% of all issues I've seen with Airconnect, are networking related. It's more than likely something to do with your docker configuration, the container config, and your host M1 Mac config that are not necessarily aligned as they need to be.

Just curious - if it works running natively, why bother trying to run it in the container? It can easily be set to run automatically or in scripted fashion on your Mac. The container route is really for running in a headless environment or server systems where you don't want it in the way on your own machines - something that runs 24/7 and you just don't think about it. Running a container on an M1 Mac Mini just adds layers of complexity that aren't needed IMO.

[1activegeek]

One other outlying thought, though I wouldn't understand the binary working directly and not in container - do you have the 10G ethernet upgrade? I actually have the M1 Mini w/ 10G, and have found an issue with AirPlay. Specifically in this instance it is actually with the actual Apple HomePod Minis, but it opens up the possibility that something about the 10G card is not quite right. I have an open issue with Apple about this and have been working for weeks on providing them logs and information to help isolate the issue. I have isolated it to the M1 w/ 10G as I have the previous gen with 10G and it works fine, and I've tried using a 1G USB-C adapter, and it works fine. Only the 10G port has an issue.

[1activegeek]

Closing as stale issue with not updates.